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ABSTRACT 


GUIDELINES  FOP.  TRAINING  SITUATION  ANALYSIS  (TSA) 


These  guidelines  represent  a  textbook  for  instruction  in  three  phases 
of  Training  Situation  Analysis  (TSA),  a  standardized  procedure,  de¬ 
veloped  by  NTDC,  for  systematically  gathering  and  interpreting  the 
information  which  is  relevant  to  the  planning  of  training  and  training 
devices . 

Three  phases  of  TSA  are  described  in  detail:  System  Familiarization, 
Task  Analysis  Method  (TAM)  and  Training  Analysis  Procedure  (TAP). 

Systems  Familiarization  provides  an  orientation  to  the  training  problem, 
the  system  structure  and  flow,  and  the  equipment.  Task  Analysis  Method 
produces  a  set  of  task  descriptions  containing  the  information  necessary 
for  making  training  device  decisions.  Training  Analysis  Procedure  pro¬ 
duces  a  ranking  of  tasks  based  upon  the  potential  benefit  to  system 
performance  as  a  result  of  training  and  the  cost  of  that  training. 
Recommendations  for  the  conduct  of  these  three  phases  and  suggested 
working  forms  are  presented. 


Qualified  requesters  may  obtain  copies  of 
this  report  direct  from  DDC. 


Reproduction  of  this  publication  in 
whole  or  in  part  is  permitted  for  any 
purpose  of  the  United  States  Government, 
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FOREWORD 


This  handbook  represents  a  major  step  in  the  formulation  of  a  quanti¬ 
fied  and  systematic  approach  to  developing  training  devices.  It  covers 
the  basic  analytic  features  of  the  Training  Situation  Analysis  (TSA) 
and  in  particular  the  human  participation  in  the  operational  system 
and  the  effects  of  training  on  operational  performance.  It  provides 
a  means  for  gathering  and  handling  only  the  information  needed  for 
making  training  decisions  and  suggests  a  means,  though  not  a  format, 
for  "turning  the  corner"  into  a  description  of  functional  training  re¬ 
quirements. 

The  Training  Analysis  Method  (TAM)  and  Training  Analysis  Procedure  (TAP) 
covered  were  developed  by  two  research  groups.  The  initial  handbook  on 
TAP*  was  published  separately  and  is  reprinted  here  with  minor  changes 
designed  to  better  accommodate  the  TAM  approach.  Limited  application 
of  the  methodology  has  been  undertaken  and  the  results  indicate  consider¬ 
able  potential  for  future  use.  The  development  of  a  single  document  to 
guide  the  analyst  through  the  maze  of  quantification  is  convenient, 
allowing  more  time  and  a  more  secure  base  for  translating  the  data  and 
findings  into  functional  characteristics.  As  a  tool,  its  utility  will 
be  directly  proportional  to  the  experience,  skill,  and  competence  of 
its  user,  and  it  in  no  way  substitutes  for  the  talents  of  the  training 
specialist. 

These  guidelines  provide  a  framework  within  which  TSA  Teams  may  operate 
more  effectively.  The  design  and  format  must  be  tested  over  time  and 
in  application  to  various  systems  and  problems.  Hopefully,  the  insights 
gained  during  use  will  result  in  whatever  changes  are  indicated.  In 
this  way  it  should  be  possible  to  incorporate  the  knowledge  of  each  TSA 
Team  for  the  benefit  of  future  groups  and  projects. 


MORTON  A.  BERTIN,  Ph.D. 
Scientific  Officer 
U.  S.  Naval  Training  Device  Center 


*NAV TRADE V CEN  1169-2,  Training  Analysis  Procedure  (TAP),  Volume  2, 
book  for  Application,  January  1964. 
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SECTION  I 

TRAINING  SITUATION  ANALYSIS  (TSA) 


A.  Introduction 


A  difficult  and  persistent  problem  facing  the  U.  S.  Naval  Training 
Device  Center,  and  other  military  installations  concerned  with  training, 
has  to  do  with  the  planning  of  training  and  training  devices  during  the 
early  stages  of  design  and  development  of  complex  man-machine  systems. 
Ideally,  the  training  programs  and  training  devices  should  become  avail¬ 
able  before  the  systems  for  which  they  were  developed  become  operational. 
Since  a  considerable  amount  of  time  is  required  to  irplement  a  training 
program  and  to  produce  and  distribute  training  devices,  the  planning  of 
these  activities  must  be  started  well  in  advance  of  the  production  of 
the  finished  system.  In  order  to  establish  a  standardized  approach  for 
the  systematic  gathering  of  the  information  which  is  relevant  to  the 
early  planning  of  training  regimens  and  training  devices,  the  Naval 
Training  Device  Center  has  developed  and  refined  a  process  called  Train¬ 
ing  Situation  Analysis  (TSA) . 

TSA  is  a  method  for  gathering,  analyzing,  and  presenting  the  infor¬ 
mation,  about  a  new  or  existing  system,  which  is  relevant  to  the  decisions 
which  need  to  be  made  about  training  support  equipment.  It  is  intended 
that  Training  Situation  Analysis  be  conducted  by  an  expert  team  of  Center 
personnel  which  has  the  blend  of  talents  and  experience  required  to  under¬ 
stand  the  human  involvement,  as  well  as  the  technical  details,  in  a 
complex  man-machine  system.  Although  the  initial  goal  of  TSA  was  to 
facilitate  training  and  training  device  decisions  for  systems  which  are 
in  early  stages  of  development,  the  process  has  been  found  equally  effec¬ 
tive  when  applied  to  operational  systems  for  which  a  training  program  must 
be  designed  or  modified.  In  fact,  the  method  is  likely  to  produce  a  more 
appropriate  training  solution  for  existing  systems,  to  the  extent  that 
the  available  information  is  more  comprehensive  and  reliable. 
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1.  Historical  Perspective 

Military  training  device  decisions  of  the  past  decade  have 
been  founded  either  upon  a  formal  method  of  task  analysis  or  upon 
informal  assessment  of  the  training  situation.  The  informal  approach 
has  produced  some  effective  training  programs.  However,  it  requires 
that  persons  with  broad  experience  and  psychological  sophistication 
perform  the  planning  function.  The  informal  approach  is  unsuccessful 
whenever  relevant  information  is  overlooked,  misinterpreted,  or  mis¬ 
applied.  The  greatest  defect  of  this  approach,  however,  is  in  the 
difficulty  of  verifying  or  challenging  the  training  solution  which  is 
produced.  One  can.  never  know,  about  any  training  program  so  devised, 
whether  all  of  the  important  aspects  of  the  man-machine  system  have 
been  considered,  whether  training  has  been  prescribed  for  those  system 
segments  which  have  the  greatest  relationship  to  system  effectiveness, 
nor  whether  the  recommended  training  program  is  particularly  well 
suited  to  teaching  the  specific  skills  and  knowledges  which  must  be 
conveyed.  It  is  extremely  difficult  to  assess,  before  the  fact, 
whether  each  training  dollar  will  be  well  spent. 

The  planning  of  a  training  program  for  a  complex  man-machine 
system  is  a  difficult  and  complex  process.  It  requires  the  integration 
of  knowledge,  techniques,  and  skills  from  the  fields  of  engineering, 
operations  analysis,  and  psychology.  Although  training  has  been  going 
on  for  a  long  time,  the  techniques  for  determining  the  content  of 
training  and  for  establishing  training  device  requirements  are  not  very 
far  advanced.  Both  rely  heavily  upon  gross  judgments  based  on 
partial  information  about  the  training  problem. 

Training  Situation  Analysis  is  a  process  whereby  decisions 
about  training  and  training  devices  will  be  more  closely  tied  to  the 
facts  that  bear  on  the  particular  training  problem.  TSA  does  not  do 
away  with  the  need  for  expert  judgment,  however.  The  value  of  the 
experience  of  experts  is  not  lost.  Instead,  TSA  organizes  the  questions 
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on  which  judgments  are  required  into  more  manageable  groups,  and  forces 
consideration  of  questions  which  might  otherwise  be  overlooked.  It 
focuses  the  expert's  attention  on  specific  problems,  rather  than  allowing 
judgments  to  be  made  on  broad  poorly  defined  questions. 

For  reasons  lost  in  the  history  of  the  development  of  training 
technology,  certain  traditions  and  beliefs  about  training  have  become 
accepted.  One  example  is  the  belief  that  operational  equipment  is  the 
best  training  equipment.  The  design  of  training  and  training  devices 
has  fallen  into  a  pattern  based  upon  such  traditions  and  beliefs — 
a  pattern  which  is  well  suited  to  some  training  situations  but  is 
inappropriate  for  others.  The  systematic,  step-by-step  approach  of  TSA 
to  training  device  decisions  preserves  those  traditions  and  beliefs  that 
are  valid,  while  eliminating,  for  good  reasons,  those  which  do  not  hold 
up  under  a  close  scrutiny  of  the  decision  processes. 

Previous  attempts  have  been  made  to  develop  formal  methods  of 
task  analysis,  so  that  training  decisions  may  be  based  upon  something 
more  substantial  than  intuitive  judgment.  However,  the  articles  in 
the  literature  dealing  with  task  analysis  describe  methodologies  that 
are  either  too  general  or  too  specific  to  be  useful.  Some  previous 
methods  of  task  analysis  have  been  devised  to  serve  a  large  number  of 
purposes.  In  addition  to  the  planning  of  training  programs,  the  authors 
claim  their  method  of  task  analysis  may  be  used  for  personnel  selection 
and  test  development,  writing  of  job  instructions,  operations  analysis, 
human  engineering  of  the  equipment,  etc.  These  methods  typically  call 
for  a  large  volume  of  information  to  be  amassed,  but  little  considera¬ 
tion  is  given  to  how  each  item  should  be  applied  to  the  decisions  which 
have  to  be  made  in  planning  training  programs.  Other  articles  describe 
task  analyses  which  were  performed  on  specific  systems.  They  describe 
how  one  particular  training  problem  was  investigated  and  the  process 
by  which  a  specific  training  solution  was  adopted.  However,  they  fail 
to  provide  a  generalizable ,  widely  applicable  procedure,  whereby  a 
sound  program  c»n  be  built  in  response  to  nearly  any  training  problem. 

It  was  to  fill  this  gap  that  the  development  of  Training  Situation 
Analysis  was  undertaken. 


3 


NAVTRADEVCEN  1218-4 


2.  Philosophy  of  TSA 

Training  devices  for  complex  man-machine  systems  are  most 
effectively  designed  as  integral  parts  of  a  training  program  to  provide 
the  means  by  which  the  tasks  to  be  learned  can  be  demonstrated  to  the 
input  trainees  or  practiced  by  them.  Each  componen4-  of  the  training 
program  is  introduced  in  response  to  a  specific  feature  of  the  train¬ 
ing  problem.  Training  devices  are  designed  to  fulfill  specific  needs 
of  the  training  program. 

Effective  training  device  design  begins  with  a  conceptuali- 
zatio.  of  each  task  in  the  system  and  a  description  of  the  manner  in 
which  it  is  to  be  performed.  Each  task  is  described  in  terms  of 
selected  attributes.  The  pattern  of  these  attributes  which  a  task 
possesses  has  implications  for  the  manner  in  which  training  should  be 

conducted  and  the  training  devices  appropriate  to  complement  that 

training.  An  inventory  is  made  of  the  skills  and  knowledges  which  a 

skilled  task  performer  must  possess  and  those  already  within  the 
repertoire  of  the  typical  input  trainee  expected  for  this  system.  The 
performance  capability  of  the  entering  trainee  is  subtracted  from  the 
skill  and  knowledge  requirement  of  each  task.  This  difference 
represents  the  training  requirement  for  that  task,  for  those  trainees. 
Training  principles  are  applied,  yielding  a  general  statement  of  the 
appropriate  course  content  and  the  kinds  of  practice  which  would 
bridge  the  gap  represented  by  the  task  training  requirement.  The 
cost  of  bridging  this  gap  is  estimated  for  each  task  which  requires 
training.  On  the  basis  of  the  cost  and  the  potential  gain  in  perfor¬ 
mance  attributable  to  training,  each  task  is  assigned  a  training  priority. 
Training  devices  are  then  designed  to  provide  the  equipment  on  which 
course  content  is  presented  cr  practice  is  held. 

Training  Situation  Analysis  is  a  procedure  for  assuring  that 
training  devices  are  introduced  to  fill  particular  needs  in  a  training 

program - a  program  which  is  based  upon  sound  training  principles,  and 

is  tailored  to  the  task,  the  trainees,  and  the  pocketbook. 
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B.  General  Description 


Training  Situation  Analysis  may  be  viewed  as  a  process  scheme  for 
getting  from  a  training  problem  to  a  training  solution.  The  five  stages 
of  TSA  and  their  interrelationships  are  shown  schematically  in  Figure  1. 
The  process  is  presented  in  terms  of  distinct  stages  performed  in  a 
specific  sequence.  In  actual  practice,  however,  the  stages  may  overlap 
considerably,  and  it  would  often  be  difficult  to  discern  where  one  ends 
and  the  next  begins.  A  considerable  portion  of  the  analysis  associated 
with  the  later  stages  is  typically  begun  in  the  earlier  stages. 

System  Familiarization — The  process  begins  with  the  analysts' 
gaining  an  orientation  to  the  training  problem,  the  system  structure 
and  flow,  and  the  equipment  which  is  involved. 

Task  Analysis  Method  (TAM) — Next  they  gather  the  particular  infor¬ 
mation,  about  human  performance  in  the  existing  or  contemplated  system, 
that  is  relevant  to  the  decisions  which  must  be  made  about  training  and 
training  devices.  The  resulting  set  of  task  descriptions  delineates 
the  relevant  attributes  of  each  task. 

Functional  Training  Requirements  (FTR) — Through  the  application  of 
training  principles,  the  profile  of  relevant  attributes  characteristic 
of  each  task  is  translated  into  the  functional  requirements  of  the 
training  regimen  indicated  for  that  task.  Functional  training  require¬ 
ments  state,  in  fundamental  terras,  what  needs  to  be  done  to  bring  about 
the  acquisition  of  each  task,  without  stating  in  great  detail  how  the 
program  is  to  be  implemented.  Derived  by  means  of  a  method  based  upon 
learning  theory  and  empirical  findings,  the  functional  training  require¬ 
ments  serve  as  the  foundation  for  the  remainder  of  the  TSA  process. 

At  this  point,  the  training  program  begins  to  take  shape. 

Training  Analysis  Procedure  (TAP) — It  is  now  possible  to  obtain 
estimates  of  training  costs  and  the  effect  of  training  upon  performance 
levels.  This  information  is  transformed  by  an  operations  analysis 
procedure  into  a  ranking  of  tasks  according  to  training  priority. 
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Figure  1.  The  Major  Stages  in  Training 
Situation  Analysis 
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Functional  Characteristics  of  the  Training  Solution— The  analysts 
set  forth  the  functional  characteristics  of  the  training  program,  designed 
for  the  acquisition  of  the  tasks  selected  in  TAP  and  baaed  on  the  functional 
training  requirements  determined  previously.  In  describing  the  training 
devices,  training  equipment,  or  training  system,  the  analysts  will  consider 
technical  feasibility,  utilization  factors,  and  training  context. 

C.  Current  Status 


Although  a  considerable  amount  of  developmental  work  has  preceded 
the  publication  of  this  document,  Training  Situation  Analysis  is  presently 
not  a  polished  procedure  which  can  be  immediately  applied  to  any  training 
problem  whatsoever  with  assured  success.  A  good  deal  of  research 
remains  to  be  done.  Portions  of  TSA  are  still  to  be  developed;  other 
portions  of  the  method,  which  are  in  a  more  advanced  stage  of  development, 
are  undergoing  continual  refinement  and  validation. 

This  document  contains  a  general  description  of  the  Training  Situation 
Analysis  concept,  devised  by  personnel  at  the  Naval  Training  Device  Center, 
as  well  as  specific  procedural  instructions  for  applying  two  of  the 
techniques  that  have  been  developed.  These  two  techniques  are  called 
Task  Analysis  Method  (TAM)  and  Training  Analysis  Procedure  (TAP) .  They 
were  devised  under  the  direction  of  the  Center,  by  Applied  Science  Associates, 
Inc.,  and  Dunlap  and  Associates,  Inc.,  respectively.  TAM  is  primarily  a 
method  for  obtaining  the  information  necessary  and  sufficient  for  arriving 
at  fundamental  decisions  about  the  characteristics  of  the  training  and 
the  training  devices  appropriate  for  each  system  task.  TAP,  on  the  other 
hand,  is  basically  a  procedure  for  utilizing  performance  and  cost 
information  to  derive  a  ranking  of  tasks  in  the  order  of  the  contribution 
their  training  can  make  to  system  performance  per  dollar  spent  in  training. 
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In  conjunction  with  the  theoretical  development  described  in  HAVTRA- 
DPiVCEN  Reports  1169-1  and  1218-1,  the  present  report  represents  the  current 
state  of  development  of  TSA.  The  most  significant  gap  in  TSA,  at  present, 
is  an  explicit  procedure  for  translating  task  description  data  into  a  set 
of  functioned  training  requirements.  However,  the  theoretical  foundation 
for  the  development  of  such  a  procedure  has  been  established  by  Folley^. 


^Tolley,  J.  D.,  Jr.  Development  of  an  Improved  Method  of  Task 
Analysis,  NAVTRADEVCEN  1218-1,  Applied  Science  Associates,  Inc. 
Appendix  A. 
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SECTION  II 

SYSTEM  FAMILIARIZATION 


A.  Classes  of  Data 


The  first  task  of  the  team  of  training  situation  analysts  should 
be  to  understand  the  training  problem  to  be  solved  and  the  system  that 
the  input  personnel  will  be  trained  to  operate.  This  orientation  will 
serve  as  the  groundwork  for  the  remainder  of  the  TSA  process.  Without 
a  fundamental  understanding  of  the  training  problem  and  the  system,  the 
final  training  solution  may  be  wide  of  its  mark. 

1 .  The  Problem 


The  training  support  problem  to  which  the  Team  is  to  apply 
itself  should  be  thoroughly  reviewed.  If  the  statement  of  the  problem 
has  obvious  defects,  they  should  be  worked  out  with  the  user  or  train¬ 
ing  agency  very  early  in  the  TSA.  In  reviewing  the  problem,  the 
■following  questions  should  be  considered: 

What  is  the  training  problem? 

Is  the  stated  problem  the  one  which  needs  to  be  solved? 

How  can  the  problem  be  better  stated? 

What  constraints  are  imposed  upon  the  training  solution? 

Are  they  realistic  constraints? 

If  the  problem  seems  well  stated,  these  questions  should  be  kept  in  mind 
as  the  TSA  is  being  performed,  until  such  time  as  some  aspect  of  the 
original  problem  seems  inappropriate.  Sometimes  the  faults  of  the 
problem  statement  do  not  become  apparent  without  a  full  investigation 
of  the  training  situation. 

Occasionally,  the  TSA  team  may  be  able  to  detect  weaknesses 
in  the  training  problem,  as  it  is  originally  stated.  The  problem  may 
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be  incompletely  or  ambiguously  stated*  The  problem  statement  may  imply 
a  specific  solution  or  class  of  solutions  which  the  TIA  team  is  apt 
prepared  to  accept  before  the  analysis  is  performed*  The  limitati©n§  ©f 
fluids  or  time,  if  these  are  included  in  the  problem  statement,  may  be 
unrealistic  in  view  of  the  stated  training  goals.  Such  matter©  should 
all  be  cleared  up  before  proceeding  with  the  TSA, 

2.  The  System 

One  of  the  primary  purposes  of  this  first  stag©  ef  TSA  i©  tg 
familiarize  the  Team  with  the  system  for  which  training  is  to  be  planned, 
The  basic  data  of  TSA  are  gathered  through  interviewing  and  the  examina¬ 
tion  of  documents.  Unless  the  Team  is  thoroughly  familiar  with  the 
system  objectives,  structure  and  flow,  the  role  of  the  human  op@?ftt§?§, 
and  the  equipment  capabilities  and  nomenclature,  there  is  likely  to  be 
a  good  deal  of  misinterpretation  of  the  basic  data  and  a  significant 
lack  of  respect  and  patience  on  the  part  of  the  informants  who  ©re 
interviewed. 

The  classes  of  information  to  be  obtained  about  tbs  system  may 
be  organized  around  three  headings:  system  objectives,  system  Ohara©’' 
teristics,  and  man-machine  characteristics.  Some  of  the  more  important 
questions  to  be  answered  under  these  three  headings  are  listed  below. 

System  Objectives— What  is  the  primary  mission  of  this  system? 
What  other  missions  is  it  able  to  perform?  What  specific  function©  ha© 
the  system  been  designed  to  perform?  Have  any  criteria  or  tolerance©  ©f 
successful  system  performance  been  established?  What  is  the  tactical 
concept  behind  this  syster.?  How  does  it  affect  existing  tactics, 
strategy,  and  doctrine?  How  does  this  system  fit  in  with  other  broader 
systems?  How  does  it  interact  with  systems  at  the  same  level  or  at 
subordinate  levels?  Is  it  a  new  system  designed  to  meet  new  needs  or 
is  it  an  improvement  on  an  existing  system?  How  did  the  requirement 
for  it  originate?  Has  any  operations  research  been  done  on  it? 
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System  Characteristics— What  are  the  principal  functional  com¬ 
ponents  of  the  system?  Which  ones  have  been  designed  especially  for  this 
system?  What  are  the  major  subsystems?  What  are  the  interrelationships 
among  subsystems?  What  are  the  events  in  a  typical  system  mission?  What 
are  the.  inputs  to  the  system?  Are  there  different  classes  of  inputs? 

For  each  class  of  input,  what  is  the  typical  rate — what  is  the  maximum 
rate  that  the  system  cam  handle?  What  operations  does  the  system  per¬ 
form  on  the  inputs?  What  determines  the  operations  that  will  be  per¬ 
formed  on  a  particular  class  of  inputs?  What  are  the  required  outputs? 

To  whom  do  they  go— in  what  forms?  What  are  normal  levels  of  system 
output?  How  can  the  quality  of  system  outputs  be  evaluated?  What  are 
the  minumum  acceptable  levelB  of  system  output?  What  is  the  maximum 
system  capability  for  the  production  of  outputs? 

Han-Machine  Characteristics — What  is  the  role  of  human  opera¬ 
tors  in  the  system?  How  many  persons  will  operate  the  system?  What 
will  be  their  differential  duties?  What  sensory  inputs  will  the  opera¬ 
tors  receive?  What  are  the  various  displays  called?  What  controls  will 
be  operated?  What  happened  when  various  controls  are  activated?  What 
will  the  various  operators  do  during  a  typical  mission?  How  will  they 
handle  unusual  contingencies  which  arise?  Will  all  of  the  operators 
work  independently  or  will  some  work  together  as  a  team?  Have  qualifi¬ 
cations  been  set  up  in  terms  of  the  intelligence,  training  or  experience 
necessary  for  the  different  positions?  Have  standards  of  speed  or 
accuracy  been  set  up  for  any  of  the  tasks?  What  sorts  of  situational 
or  environmental  stresses  will  the  operators  be  under?  What  special 
precautions  must  be  taken  for  the  sake  of  the  safety  of  personnel  or 
equipment?  What  aspects  of  the  system  will  cause  special  difficulties 
in  training? 

B.  Sources  of  Data 

In  this  important  phase  of  TSA,  several  different  data  sources 
may  be  used  in  formulating  an  accurate  description  of  the  system. 

These  include: 
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.  System  Documentation 

.  System  Observation 

.  Personnel  Interview 

The  following  sections  provide  some  guidelines  for  using  these  sources 
effectively  in  acquiring  an  understanding  of  the  system. 

/.  .  System  Documentation 

The  initial  effort  in  the  system  familiarization  phase  should 
be  devoted  to  gathering  all  available  documentation  pertaining  to  the 
subject  system.  These  documents  may  include  manufacturers'  or  service- 
published  system  operation  manuals,  field  manuals,  operating  command 
SOP' 8,  or,  in  rare  instances,  previously  compiled  task  aneilysis  data. 

These  documents  should  be  reviewed  thoroughly  and  studied  in  detail  to 
provide  a  baisic  understanding  of  the  system  mission,  operating  modes, 
number  and  kinds  of  consoles  and  control-display  devices,  and  number 
and  kinds  of  operating  personnel  and  their  general  functional  respon¬ 
sibilities.  From  these  sources,  the  analyst  should  attempt  to  establish 
a  first-cut  description  of  system  flow.  It  is  often  helpful  to  chart 
the  flow  of  events.  The  analyst  may  use  his  own  method  of  flow-charting 
or  adopt  the  OSD  technique  described  on  page  14. 

The  level  of  understanding  which  can  be  acquired  from  documents 
depends  upon  the  number  of  documents  and  the  relevance  of  the  subject 
matter  jf  the  documents  to  the  areas  of 'concern.  Typically,  the  areas 
of  most  vital  interest  to  the  TSA  team,  those  having  to  do  with  human 
participation  in  the  operation  of  the  system,  will  be  least  adequately 
described.  The  Team  will  have  to  turn  to  other  sources  of  information. 

.  System  Observation 

Having  acquired  a  preliminary  orientation  to  the  system  from 
the  available  documents,  the  next  important  step  to  be  taken,  wherever 
possible,  is  to  observe  the  system  as  a  physical  reality.  Preferably,  the 
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system  should  be  seen  while  it  is  operating,  on  either  real  or  synthetic 
data.  Of  greatest  benefit  is  to  receive  a  "talk- through,"  as  the 
operation  proceeds,  from  knowledgeable  personnel  who  are  not  actually 
participating  in  the  operation.  Several  such  observations  may  be 
required,  depending  upon  the  complexity  of  the  system.  Whenever  possible, 
it  is  advisable  to  observe  the  way  in  which  several  operators  perform 
the  same  task.  In  this  way,  the  analyst  is  better  able  to  differentiate 
between  the  attributes  of  performance  which  are  characteristic  of  the 
task  and  those  which  are  characteristic  of  a  particular  task  performer. 
During  the  first  observation,  the  analyst  should  confirm  his  understanding 
of  the  system  as  derived  from  the  documentation.  Any  discrepancy  between 
his  understanding  of  the  system  operations  and  equipments  as  derived  from 
the  documentation,  and  his  observations  during  system  operation, 
should  be  cleared  up  at  the  earliest  opportunity. 

When  observing  a  system  in  operation,  particularly  a  system 
with  several  operating  modes,  it  is  important  to  note  the  conditions  under 
which  the  system  is  operating  or  the  mode  in  which  it  is  operating.  If 
modes  shift  during  the  observation,  it  should  be  determined  what  events 
precipitated  the  shift  and  what  changes  in  procedure,  function,  or 
responsibility  took  place. 

While  in  the  observation  situation,  the  analyst  should  attempt 
to  acquire  the  confidence  of  the  operating  personnel  and  enlist  their 
cooperation  for  future  performance  data  collection.  Every  effort  should 
be  made  to  explain  the  purpose  of  the  study  and  its  potential  benefit  for 
future  training  in  the  subject  system.  Operating  personnel  can  prove 
to  be  a  valuable  source  of  information  during  all  phases  of  the  TSA 
process . 


Personnel  Interviews 


Wherever  possible,  system  description  should  be  developed  with 
the  aid  of  operating  personnel.  A  series  of  discussions  with  these 
knowledgeable  individuals  will  generally  prove  to  be  the  most  valuable 

* 
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portion  of  any  visit  to  an  operational  site.  The  analyst  should  interview 
as  many  operators  as  he  can.  The  greater  the  number  of  operating  personnel 
that  are  interviewed  in  connection  with  each  task,  the  more  reliable  will 
be  the  analysts'  information.  The  analysts*  first  exposure  to  system 
personnel  may  be  during  the  first  observation  period.  At  this  time,  the 
analysts  should  seek  to  make  their  understanding  of  the  system  conform 
to  actual  operating  procedures.  The  system  flow  should  be  established  and 
confirmed.  It  is  particularly  important  to  get  firsthand  knowledge  of 
possible  contingency  situations  (see  p.  25)  and  how  they  are  handled. 

Quite  often,  the  manner  in  which  the  system  copes  with  contingencies  is 
a  matter  of  local  SOP  and  is  not  documented. 

The  nature  of  the  tasks,  particularly  those  which  are  unique 
to  this  system,  should  be  discussed  with  operating  personnel  in  antici¬ 
pation  of  collecting  data  in  the  later  stages  of  TSA.  At  this  time,  the 
task  should  be  completely  understood,  so  the  future  interrogation  may 
be  properly  structured  and  efficiently  conducted. 

C.  The  Operational  Sequence  Diagram  (OSD) 

An  understanding  of  the  sequence  of  events  in  the  operation  of  a 
system  may  be  considerably  enhanced  by  the  use  of  graphic  techniques. 

One  of  the  techniques  currently  being  employed  in  system  analysis  is 

p 

the  Operational  Sequence  Diagram,  or  OSD  .  The  OSD  is  a  tool  for  rep¬ 
resenting  pictorially  the  interactions  among  the  men  and  machines  in  a 
system. 

The  use  of  OSD's  within  TSA  may  be  considered  as  an  optional 
technique  which  can  serve  the  purpose  of  testing,  crystallizing,  and 
extending  the  Team's  understanding  of  the  basic  processes  of  which  the 
system  is  composed.  It  is  optional  in  the  sense  that  if  a  thorough 

a**"1 . .  •  ~~  . . . .  ■ 

Brooks,  F.  A.,  Jr.  Operational  sequence  diagrams.  Inst.  Radio  Engrs. 
Trans.  Human  Factors  in  Electron. ,  I960 ,  1 ,  35-34 
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analysis  of  the  system  from  the  standpoint  of  human  involvement  has 
been  previously  performed  there  is  no  need  to  repeat  the  process.  If 
there  exist  many  exoellent  operator-oriented  documents  with  standard 
procedures 4  time-line  Charts,  information  flow  diagrams,  and  statements 
of  duties  and  responsibilities,  there  may  be  little  need  for  OSD's. 

System  familiarisation  can  be  rapidly  acquired  without  this  technique. 
Unfortunately  for  TSA  analysts,  this  is  not  the  usual  state  of  affairs. 
Typically,  nearly  all  of  the  available  documents  are  devoted  to  des¬ 
cribing  the  functioning  and  capabilities  of  the  equipment.  They  are 
written  for  the  engineer,  not  for  the  training  specialist. 

When  the  analysts  must  gain  an  understanding  of  system  function¬ 
ing  through  intensive  independent  investigation,  the  OSD  provides  an 
excellent  means  for  assuring  the  uniformity,  completeness,  and  accuracy 
of  that  understanding.  Preparation  of  OSD's  forces  the  analysts  to  be 
comprehensive  in  their  understanding  of  the  system.  It  demands  con¬ 
tinuity  in  system  flow;  it  establishes  the  relationships  between  opera¬ 
tors  and  equipment  (and,  more  importantly,  among  tasks).  Once  prepared, 
it  serves  as  an  excellent  basis  for  discussion  with  operating  personnel 
in  confirming  the  analysts'  understanding;  of  the  system. 

The  basic  components  of  the  OSD  are  various  geometric  figures 
coded  to  denote  the  elements  of  any  operational  sequence  (see  Figure  2). 
These  figures  are  drawn  in  columns  which  represent  the  various  positions 
and  equipments  in  the  system.  They  are  interconnected  by  solid  or  dashed 
lines  which  represent  the  sequential  interrelationships  among  elements. 
OSD's  are  often  drawn  with  a  vertical  time  scale  along  the  left  border. 
The  length  of  the  vertical  solid  interconnecting  lines  represents  time 
between  the  elements.  Horizontal  lines  show  information  links  among 
equipments  and  operators.  A  dashed  vertical  line  is  used  to  indicate 
a  time  delay  in  sin  operational  sequence. 
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Squares  on  the  diagram  are  used  to  indicate  actions.  Triangles 
are  used  to  indicate  the  transmission  of  information,  in  the  broadest 
sense  of  the  term,  and  circles  stand  for  the  reception  of  information. 
Decisions  or  discriminations*  sire  shown  by  hexagons.  A  cup-shaped 
symbol  is  used  to  represent  information  storage.  With  this  symbol, 
information  may  be  shown  being  placed  into  storage  or  withdrawn  from 
storage. 

Whenever  symbols  are  drawn  with  a  single  line,  they  represent 
human  behavior.  Double-line  symbols  represent  operations  performed 
automatically  by  machines.  A  symbol  which  is  filled  has  the  meaning 
opposite  from  that  of  a  line-drawn  symbol  of  the  same  shape.  Filled 
symbols  are  most  often  used  in  conjunction  with  hexagons  (decisions) 
to  show  that  one  possible  alternative  of  the  decision  is  "inaction." 


The  analyst  should  be  cautioned  that  the  distinction  between  decision 
and  discrimination  which  is  obscured  in  the  OSD  must  later  be  preserved 
when  the  analyst  undertakes  the  TAM  analysis  of  the  system  (see  p.53). 
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SECTION  III 
GUIDELINES  FOR 
TASK  ANALYSIS  METHOD  (TAM) 


A.  Introduction  to  TAM 


The  Task  Analysis  Method  (TAM)  has  been  devised  to  direct  the  atten¬ 
tion  of  Training  Situation  Analysts  to  the  aspects  of  a  complex  man-machine 
system  which  will  help  them  decide  hew  training  for  that  system  should 
be  conducted.  It  is  basically  a  procedure  for  obtaining  and  abstracting 
selected  information  about  the  human  participation  in  a  system.  However, 
no  set  of  suggestions  or  rules  can  reduce  task  analysis  to  a  simple, 
routine  job.  The  description  of  human  behavior  is  too  complex,  and  the 
number  and  variety  of  tasks  too  great  to  permit  reduction  of  task  analysis 
to  a  simple  routine;  These  guidelines  will  not  do  the  job  for  the 
analyst.  They  will,  hopefully,  help  him  do  his  job  better. 

These  guidelines  have  been  set  up  so  that  only  the  information 
necessary  and  sufficient  to  meet  the  objectives  of  task  analysis  is 
collected.  The  amount  of  information  to  be  collected,  therefore,  probably 
is  less  than  in  other  forms  of  task  analysis.  The  amount  of  effort 
required  of  the  task  analyst  is  probably  about  the  same  as  with  earlier 
methods,  however,  because  the  guidelines  require  collection  of  some  in¬ 
formation  that  is  difficult  to  obtain. 

The  primary  difference  between  the  present  method  and  previous 
methods  is  the  direction  in  which  the  analyst's  efforts  are  channeled. 
Under  previous  methods,  for  example,  the  details  of  every  step  of  a 
lengthy  procedural  task  may  have  been  written  out;  under  the  present 
method  this  part  of  the  task  is  merely  identified  as  "procedure  follow¬ 
ing."  The  major  effort  is  then  directed  toward  determining  the  factors 
associated  with  following  that  procedure  which  may  generate  training 
requirements  most  appropriate  to  that  specific  kind  of  activity.  The 
same  approach  is  used  with  other  types  of  activities  within  tasks. 
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4  This  introduction  presents  some  basic  ideas  that  the  analyst 

should  understand  before  getting  into  the  instructions  for  task  analysis. 
The  remainder  of  this  section  presents  the  stages  of  the  task  analysis 
method  essentially  in  the  order  in  which  they  would  normally  be  performed. 
Examples  are  given  to  illustrate  the  type  of  data  required,  and  dis¬ 
cussions  of  special  problems  or  techniques  are  included  where  they 
clarify  the  instructions. 

1.  The  Nature  of  Task  Analysis 

.  Task  Analysis  vs.  Task  Description 

Task  analysis  is  a  process  in  which  a  task  is  examined 
and  its  characteristics,  in  terms  of  certain  attributes,  are  identified. 
The  particular  attributes  which  are  used  depend  on  the  objectives  of 
the  analysis.  Task  analysis  produces  task  descriptions. 

The  task  description  is  a  product,  a  thing,  a  body  of 
information,  a  set  of  statements  about  a  task  which  characterize  that 
task  in  terms  of  selected  attributes.  The  task  description  resulting 
from  task  analysis  is  then  used  as  the  basis  for  certain  decisions.  In 
the  case  of  TAM,  the  task  description  is  applied  to  decisions  about 
training.  These  guidelines  suggest  ways  of  performing  the  task  analysis 
in  such  a  way  that  the  resulting  task  description  is  most  applicable  to 
training  decisions. 

.  The  Content  of  Task  Descriptions 

Describing  a  task  is  like  describing  a  person.  You  can 
say  many  things  about  either.  The  choice  of  information  to  be  mentioned 
depends  on  what  you  want  to  do  with  the  description.  For  example,  if  you 
want  to  describe  a  man  to  hi15  tailor,  you  would  use  a  standard  set  of 
body  measurements  expressed  in  the  form  of  clothing  sizes.  The  size  of 
the  person  is  the  information  relevant  to  the  tailor's  purpose  of  making 
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a  suit.  In  describing  the  same  person  to  a  personnel  manager,  you  would 
be  much  more  likely  to  say  something  about  his  aptitudes,  intelligence 
and  personality  characteristics.  These  are  the  kinds  of  information  the 
personnel  man  needs  to  know  about  the  person  in  order  to  decide  whether 
to  hire  him.  Clothing  sizes  do  not  help. 

In  describing  tasks,  picking  the  right  information  is  also 
important.  If  you  were  going  to  redesign  an  operator's  panel,  a  link 
analysis  of  the  sequential  movements  would  be  very  useful.  In  deciding 
on  training  requirements,  the  kinds  of  behaviors  present  in  the  task 
would  be  more  relevant. 

It  is  important,  therefore,  to  keep  in  mind  that  task 
analysis  is  the  process  of  collecting  particular  kinds  of  information 

about  the  tasks.  Merely  collecting  a  large  amount  of  information  does 
not  necessarily  result  in  a  good  task  analysis. 

Certain  kinds  of  information  about  tasks  are  more  easily 
obtained  than  other  kinds.  Going  back  to  the  analogy  of  describing  a 
person — it  is  much  easier  to  determine  his  suit  size  than  to  obtain  a 
description  of  his  personality  characteristics.  In  general,  the  reason 
for  this  difference  is  that  there  exists  a  standard,  generally  accepted 
method  and  scale  for  determining  suit  size.  This  is  not  true  for 
personality. 


Task  analysis  is  similar  in  that  some  attributes  are 
easily  identified,  while  others  are  not.  It  is  relatively  easy  to 
determine  the  number  of  controls  and  displays  that  must  be  used  in  a 
certain  task.  Determining  the  behavioral  requirements  of  a  task  and 
describing  them  in  a  meaningful  way  is  a  tougher  problem.  There  is  no 
standard,  generally  accepted  way  to  describe  behavioral  requirements 
meaningfully.  At  the  present  state  of  the  art,  you  cannot  go  to  a 
standard  behavior  list  and  pick  out  the  ones  that  apply  to  the 
particular  task  you  are  analyzing. 
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These  facts  have  two  implications  for  the  task  analyst: 

(a.)  Because  some  kinds  of  task  data  are  easier  to  get 
than  others,  there  is  a  temptation  to  fill  up  or  fill  out  the  task 
description  with  this  more  readily  available  information.  The  sub¬ 
stitution  of  quantity  for  relevance  is  not  very  helpful.  The  personnel 
man  cannot  legitimately  decide  whether  to  hire  an  applicant  on  the  basis 
of  a  complete  listing  of  all  thj  applicant's  clothing  sizes.  Training 
decisions  cannot  be  made  on  the  basis  of  task  data  which  are  not 
relevant  to  training,  no  matter  how  much  of  this  non- relevant  informa¬ 
tion  is  collected. 

(b.)  Because  the  most  important  kinds  of  task  data  are 
also  the  most  difficult  to  obtain,  great  demands  are  placed  on  the 
judgement,  insight,  intelligence,  and  information-collecting  ability  of 
the  task  analyst.  ^ 

2.  The  Nature  of  the  Task  Analyst 


Characteristics 


In  order  to  do  his  job  well,  the  task  analyst  must  be  a 
little  like  the  chaplain  in  some  respects — he  must  be  a  tower  of  strength 
and  of  tolerance,  and  have  some  appreciation  of  the  problems  of  everyone 
he  deals  with.  The  variety  of  situations  in  which  he  must  work,  the 
different  kinds  of  people  he  must  deal  with,  and  the  fact  that  he  almost 
always  intrudes  himself  and  his  questions  into  someone  else's  ongoing 
work  emphasizes  the  inherent  difficulty  of  doing  task  analysis. 

The  task  analyst's  strength  must  lie  in  his  persistence 
to  seek  out  and  obtain  the  required  task  data.  Every  item  of  information 
called  for  in  these  guidelines  fills  a  specific  need  in  making  training 
decisions.  Omission  of  any  item  means  that  some  training  decision  will 
have  to  be  made  less  objectively  and  less  effectively,  with  the  ultimate 
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result  that  training,  and,  consequently,  system  operation,  will  probably 
be  less  effective.  For  example,  if  data  on  contingencies  are  inadequate, 
ample  provisions  may  not  be  made  in  training  devices  or  in  the  training 
program  for  trainees  to  practice  handling  the  kinds  of  contingencies 
that  may  arise  in  task  performance. 

.  Adaptability 

Task  analyses  vary  widely  in  their  scope  and  information 
requirements.  Sometimes  analyses  will  be  required  on  all  tasks  in  a 
large  weapon  system.  In  other  cases  an  analysis  of  a  single  task,  such 
as  firing  a  rifle  at  a  moving  target,  may  be  the  extent  of  the  require¬ 
ment.  The  analyst  must  adapt  his  methods  and  approach  to  meet  these  dif¬ 
ferent  needs. 


.  Overcoming  Resistance 

Because  he  intrudes  his  difficult  questions  into  the 
normal  work  routine  of  other  people,  the  task  analyst  must  expect  some 
resistance  to  providing  the  data  he  needs.  He  must  tolerate  and  "wait 
out"  what  in  some  cases  may  seem  unreasonable  objections  or  questions 
regarding  his  work  if  he  is  to  obtain  the  required  data.  For  example, 
personnel  in  operating  units  may  fail  to  see  the  important  role  that 
task  analysis  plays  in  ultimately  providing  trained  replacements  for 
their  unit,  or  in  providing  personnel  adequately  trained  on  new  equip¬ 
ment  which  the  unit  may  be  receiving  in  the  future.  In  consequence, 
these  operating  personnel  may  be  reluctant  to  interrupt  their  activities 
to  provide  the  needed  task  data.  The  task  analyst  must  be  ready  and 
able  to  show  them  that  the  information  he  needs  is  important. 

.  Obtaining  Accurate  Information 

In  most  cases,  the  task  analyst  cannot  observe  perfor¬ 
mance  of  the  task  he  is  to  describe.  Frequently  he  cannot  even  see 
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i*  the  equipment  involved.  He  has  to  depend,  rather,  on  second-hand  in- 

formation  obtained  from  system  experts  or  other  informants  with  vary¬ 
ing  degrees  of  information  about  the  task.  In  many  cases,  these  in¬ 
formants  will  have  little  knowledge  or  appreciation  of  the  problems 
and  purposes  of  task  analysis  or  Training  Situation  Analysis.  If  he  is 
to  obtain  accurate  task  descriptions,  the  task  analyst  must  develop 
considerable  skill  at  asking  questions,  and  at  conveying  to  his  infor¬ 
mants  an  appreciation  of  the  kinds  of  information  needed  and  the  way  in 
which  it  will  be  used.  It  is  also  important  that  the  analyst  ask  the  same 
questions  of  more  than  one  informant.  This  will  enhance  the  completeness 
and  the  accuracy  of  the  resulting  task  descriptions. 

The  task  analyst  must  realize  that  most  of  his  informants 
will  have  a  point  of  view  different  from  his,  and  that  the  questions  he 
asks  and  the  answers  he  gets  may  have  very  different  meaning  to  the 
informant  than  to  the  task  analyst.  For  example,  in  trying  to  learn  about 
a  task,  the  analyst  may  ask  "What  is  the  most  difficult  part  of  this  task?" 
The  system  designer-informant  may  report,  for  example,  that  accurate 
aiming  of  the  missile  is  most  difficult.  From  his  point  of  view— presum¬ 
ably  system  performance — this  may  be  true.  Behaviorally ,  however,  the 
operation  may  be  as  simple  as  pointing  an  automatic  theodolite  toward  a 
specified  point  and  pressing  the  "automatic  lock-on"  button.  The  infor¬ 
mant  has  given  what  to  him  is  an  honest,  accurate  answer  to  the  question. 
But  the  answer,  if  accepted  at  face  value,  may  give  a  very  erroneous 
impression  of  the  nature  of  the  task  involved. 

The  system  designer  may  not  have  been  accustomed  to  factor¬ 
ing  out  the  human  operator’s  part  of  the  operation  and  analyzing  it 
separately.  The  task  analyst  must  be  capable  of  evaluating  the  answers 
given  by  his  informants  and  be  ready  to  probe  with  more  questions  to  get 
the  information  he  needs.  For  example,  in  response  to  the  above  answer 
the  analyst  might  ask  what  aspect  of  aiming  the  missile  made  the  task 
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cJfficult,  From  the  informant's  answer  it  may  be  apparent  that  he  is 
not  talking  about  human  participation.  The  analyst  can  then  inquire 
further  about  the  aspects  of  operator  performance  which  made  the  task 
difficult. 

3.  Some  Basic  Definitions 

Activity — The  term  "activity"  has  a  special  meaning  in  TAM.  It 
refers  to  a  class  of  task  behaviors.  TAM  describes  every  task  in  terms  of 
the  apportionment  of  the  operator's  attention  among  six  activities  (see 
p  5Cffi :  procedure  following,  continuous  perceptual-motor  activity, 
monitoring,  communicating,  decision  making,  and  non- task-related  activity. 

The  resulting  profile  of  activities  has  relevance  to  the  training 
decisions  which  must  be  made  about  the  task. 

Event — A  discrete,  identifiable  act  or  occurrence.  Examples: 

(a)  Depress  "Power"  button,  (b)  Time  reaches  0900. 

Task— A  collection  of  activities  that  are:  (a)  performed  by 
one  person,  (b)  bounded  by  two  events,  (c)  directed  toward  achieving  a 
single  objective  or  output,,  and  (d)  describable  by  means  of  the  method 
set  forth  in-  these  guidelines,  so  that'  the  resulting  task  description 

t  *  ^ 

conveys  enough  information  about-  the  task  to  permit  the  necessary 
training  decisions  to  be  made. 

Position — The  group  of  tasks  assigned  to  one  person  in  an 

— — — 

operational  or  maintenance  situation. 

Block  or  Major  System  Function-  -A  grrJ^p'of  tasks  or  system  i 

operations  occurring  during  the  samd  period  of  time,  all  directed  toward 
achieving  the  same  sub-objective  in  the  mission  of  the  system.  Human 
participation  may  be  partially  or  completely  absent  from  a  block. 

Typically,  however,  a  block  is  composed  of  tasks  performed  by  the 
operators. 
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Performance  Requirements — The  minimum  level  of  performance 
(for  a  task,  block,  or  system)  that  would  be  considered  acceptable — 
that  would  not  jeopardize  accomplishment  of  the  mission  within  prescribed 
limits  of  time  and  accuracy. 

Adverse  Conditions — Enviromental  or  situational  factors 
which  act  to  degrade  dr  disrupt  task  performance.  When  adverse  condi¬ 
tions  are  present,  the  operator  generally  has  to  put  forth  greater 
effort  in  an  attempt  to  maintain  normal  procedures  and  a  normal  rate  of 
performance. 

Contingencies — Events  occurring  during  task  performance  that 
cause  disruption  of  "normal"  or  expected  activity  in  the  task. 

4.  Phases  of  Task  Analysis 

Training  decisions  are,  not  made  all  at  one  time,  but  are  made 
in  gradually  refined  stages.  Task  analysis  can  and  should  progress  in 
the  same  way.  After  a  certain  amount  of  information  is  obtained, 
training  decisions  can  be  made  to  a  certain  level  of  detail.  As  more 
task  information  is  collected,  the  training  decisions  can  be  refined. 

For  example,  as  soon  as  it  is  determined  that  a  task  contains  relatively 
difficult  tracking  behavior,  the  decision  can  be  made  that  a  device  will 
probably  be  needed  on  which  trainees  can  practice  this  part  of  the  task. 
Funds  and  time  can  then  be  allocated  for  developing  such  a  device  and 
for  including  the  practice  in  training.  Later  analysis  of  the  task  may 
indicate  the  critical  cues  and  responses  in  the  tracking  part  of  the 
task.  This  added  information  permits  decisions  to  be  made  about  the 
specific  characteristics  of  the  device,  such  as  the  aspects  of  the 
task  which  need  to  be  simulated  and  the  required  degree  of  simulation. 
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In  keeping  with  this  kind  of  progression,  task  analysis  proceeds 
from  large  units  of  system  operation  to  successively  smaller  units,  in¬ 
creasing  the  amount  of  information  obtained  about  human  participation  as 
it  progresses. 

In  developing  a  task  analysis,  it  is  necessary  to  obtain  a 
reliable  list  of  tasks  as  a  starting  point.  It  is  almost  impossible  to 
specify  a  single  approach  to  task  identification  that  is  best  for  every 
system  and  every  situation.  In  some  cases  it  is  best  to  ask  about  and 
to  list  tasks  directly.  In  other  cases  it  is  helpful  to  divide  the 
overall  system  operation  into  major  operating  stages  (herein  referred 
to  as  blocks),  and  then  identify  the  individual  tasks  within  each  stage. 


The  operating  stages  approach  is  most  effective  in  those  cases 
where  the  total  of  system  activity  is  of  fairly  long  duration,  and 
proceeds  in  readily  identifiable  blocks.  An  example  is  the  receipt, 
preparation,  and  firing  of  a  large  weapon.  In  this  example  the  stages 
or  blocks  might  be: 

1.  Accept  and  inspect  weapon 

2.  Assemble  weapon 

3.  Check  out  weapon 

4.  Position  weapon 

5.  Check  assigned  targets  within  range 

6.  Establish  ready-to-fire  condition 

7.  Prep"' -  •  ,o-fire  and  fire 

8.  Tra"?;  to  target 

9.  Scheduled  maintenance 

10.  Unscheduled  maintenance 


Each  of  these  blocks  will  contain  many  tasks,  or  system 
operations,  which  will  be  identified  block  by  block. 
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Assuming  the  more  inclusive  approach  for  this  presentation,  the 
phases  of  development  of  task  analysis  and  the  kinds  of  information  ob¬ 
tained  in  each  phase  are  shown  in  Table  1. 

Since  the  starting  point  for  task  analysis  will  vary  from  system 
to  system,  the  task  analyst  will  have  to  use  his  judgment  in  each  case 
so  as  not  to  repeat  work  already  done  under  a  different  title.  The 
major  steps  given  below  are  the  steps  that  have  to  be  done.  If  any 
have  been  completed  at  the  time  task  analysis  is  bogun,  obviously  they 
need  not  be  done  again. 


Units  within  which 

Phase _ data  are  obtained 

Development  of: 

1.  System  Block  Analysis  Whole  System 
(SBA) 


2 .  Task-Time  Charts 
(TTC) 


Operating  stages  or 
whole  system 


3.  Functional  Task  Tasks 

Descriptions  (FTD) 

4.  Behavioral  Details  Activities  in  tasks 

Descriptions  (BDD) 


Kind  of  data  obtained 


Major  system  operations, 
arranged  according  to 
sequence  and  time,  when 
possible . 

Identification  of  tasks 
and  relationships  among 
tasks . 

Activities  within  tasks 
and  relationships  among 
activities . 

Detailed  characteristics 
of  activities. 


Table  1.  Stages  in  Task  Analysis  and  Kind 
of  Data  Obtained  in  Bach  Stage 

B .  Development  of  System  Block  Analysis 


The  System  Block  Analysis  is  primarily  a  list  of  major  blocks  of 
tasks  or  major  system  operations  into  which  a  system  can  be  partitioned. 
It  also  indicates  the  sequence  in  which  the  blocks  occur  where  sequence 
is  important.  If  the  blocks  do  not  occur  in  a  particular  order,  this  too 
is  indicated.  In  some  systems  the  blocks  occur  in  series;  other  systems 
will  have  blocks  which  are  concurrent  or  which  overlap  in  time. 
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The  word  "block,"  as  it  is  used  here,  refers  to  a  group  of  tasks  or 
major  system  operations,  all  of  which  are  directed  toward  the  same  subgoal 
in  the  functioning  of  the  system.  An  example  of  a  block  is  "Check  the 
missile."  Many  tasks  may  be  performed  to  check  the  missile,  but  all  tasks 
in  the  block  are  directed  toward  accomplishing  that  objective.  When  that 
subgoal  is  achieved,  the  men  direct  their  efforts  toward  a  different  subgoal , 
and  begin  working  on  a  different  block  of  tasks. 

Some  blocks  in  a  system  may  include  no  manned  operations.  These  major 
automatic  operations  are  included  in  the  System  Block  Analysis  for  the  sake 
of  presenting  a  complete  picture  of  system  functioning.  When  such  functions 
exist,  the  analyst  should  be  aware  of  it,  insofar  as  manned  operations 
supply  inputs  to  them  or  accept  inputs  from  them.  However,  since  they  impose 
no  need  for  training,  they  may  be  otherwise  disregarded  in  the  remainder 
of  TAM. 

If  the  system  has  several  modes  of  operation  you  will  have  to  treat 
each  mode  separately  in  the  next  stage  of  TAM  (development  of  Task-Time 
Charts).  Therefore,  you  will  need  to  construct  a  separate  System  Block 
Analysis  for  each  mode  of  operation. 

The  first  step  in  identifying  blocks  is  to  ask  the  informant  to  give 
a  narrative  description  of  the  typical  operation  of  the  system.  During 
this  narrative  description,  you  should  take  notes  and  ask  questions  for 
clarification,  to  correct  apparent  inconsistencies,  and  to  close  any 
obvious  gaps  in  the  narrative.  Then  you  should  review  your  notes  with  the 
informant  in  an  attempt  to  identify  the  major  phases  or  blocks  into  which 
the  system  operation  can  be  partitioned.  Try  to  find  logical  functional 
groups  of  tasks  which  have  a  common  subgoal.  In  some  cases  the  informant 
will  have  a  clear  notion  of  the  way  in  which  tasks  should  be  grouped.  In 
other  cases  you  may  have  to  propose  blocks  that  seem  meaningful  and  reason¬ 
able  to  you,  and  confirm  your  judgment  with  the  informant. 
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To  each  block  which  is  identified,  you  will  attach  a  descriptive 
name.  The  final  product  of  the  System  Block  Analysis  will  be  a  list  of 
blocks.  Beside  the  name  of  each  block,  indicate  any  prerequisite  block 
or  any  time  constraints  which  might  apply  to  the  initiation  of  that  block. 
Some  examples  are: 

Follows  immediately  after  Block  7. 

Performed  as  needed. 

Performed  on  request. 

May  be  begun  any  time  after  Block  13  is  finished. 

Performed  throughout  the  operation  of  the  system. 

An  example  of  part  of  a  System  Block  Analysis  is  given  in  Figure  3* 


Block 

Number 

Block  Name 

Remarks 

1.0 

Accept  &  inspect  weapon 

2.0 

Assemble  weapon 

Follows 

Block  1 

3-0 

Check  out  weapon 

Follows 

Block  2,  9»  c 

4.0 

Position  weapon 

Follows 

Block  3 

NO 

Check  assigned  targets  within  range 

Follows 

Block  4 

6.0 

Establish  Ready-to-Fire  condition 

Follows 

Block  5 

7.0 

Prepare-to-fire  and  fire 

Follows 

Block  6 

8.0 

Travel  to  target 

Follows 

Block  7 

9.0 

Scheduled  maintenance 

On  regular  schedule 

10.0 

Unscheduled  maintenance 

As  required 

Figure  3.  Part  of  a  System  Block  Analysis 


C.  Development  of  Task-Time  Charts 

The  following  description  of  the  analysis  process  will  assure  that 
System  Block  Analysis  has  been  performed  and  is  being  used.  This  phase 
of  the  analysis  is  intended  to  achieve  four  objectives  for  each  block  or, 
if  blocks  are  not  being  used,  for  all  system  tasks  taken  as  a  unit.  The 
objectives  are: 
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1.  Identify  the  tasks  and  determine  which  person  (position) 
performs  each  task. 

2.  Determine  typical  total  time  for  the  block. 

3.  Determine  typical  task  duration  and  coordination  requirements. 

4.  Determine  any  adverse  conditions  which  affect,  in  the  same 
manner,  all  tasks  being  performed  simultaneously. 

An  example  of  a  completed  Task-Time  Chart  is  shown  in  Figure  4.  You 
are  urged  to  fold  out  the  chart  and  to  follow  this  example  as  you  read  the 
instructions  for  the  accomplishment  of  these  objectives.  (Note  that  the 
chart  faces  backward  for  ready  reference  of  later  pages.) 

1.  Task  Identification 

The  identification  of  tasks  is  one  of  the  central  steps  in  TSA. 
It  determines  the  course  of  much  of  the  analysis  to  follow  and  influences 
the  structure  of  the  training  program  to  be  developed.  Unfortunately, 
there  are  no  hard  and  fast  rules  for  identifying  the  set  of  activities 
which  comprise  a  task.  You  will  initially  have  to  rely  on  interviews 
with  system  experts  to  provide  this  information.  Your  ability  to  identify 
the  tasks  in  a  system  will  improve  with  your  experience  in  performing 
TSA.  There  are,  however,  some  fundamental  criteria  to  assist  you  in  task 
identification. 

A  task  should  have  an  identifiable  process  performed  by  one 
person.  This  process  must  have  an  objective  or  output  which  is  related 
to  the  goal  or  mission  of  the  system.  Not  all  tasks  are  of  equal  length, 
difficulty,  or  complexity,  nor  are  they  equally  critical  to  the  operation 
of  the  system.  Some  tasks  may  take  seconds  to  perform,  while  others  may 
take  hours.  Some  may  be  highly  equipment-oriented,  procedural  tasks, 
while  others  may  involve  only  mental  integration  or  decision  making. 
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Tasks  are  bounded  by  two  events.  The  initiating  event  may  be 
the  receipt  of  a  signal  from  the  external  environment  or  the  receipt  of 
the  output  of  another  operator's  task.  It  may  be,  for  example,  the 
receipt  of  communications,  the  detection  of  a  radar  target,  or  the  lighting 
of  a  lamp  on  a  console.  The  terminating  event  of  a  task  is,  in  most 
cases,  the  achievement  of  the  task  output  or  the  initiation  of  a  com¬ 
munication  indicating  that  the  task  goal  has  been  achieved. 

A  task  is  a  collection  of  activities  that  are  describable  by 
means  of  the  methods  set  forth  in  these  guidelines,  so  that  the  resulting 
task  description  conveys  enough  information  about  the  task  to  permit  the 
necessary  training  decisions  to  be  made.  This  criterion  for  the  identi¬ 
fication  of  a  task  is  a  circular  one,  but  an  important  one.  It  cannot 
be  applied  by  an  analyst  until  he  is  thoroughly  familiar  with  TAM  and  the 
other  stages  of  TSA.  Nevertheless,  it  draws  attention  to  the  fact  that 
data  must  be  obtained  and  training  decisions  must  be  made  about  every 
unit  of  behavior  that  is  called  a  task.  As  the  analyst  becomes  familiar 
with  the  data  and  decisions  which  TSA  calls  for,  he  will  acquire  an  ap¬ 
preciation  of  the  level  of  behavioral  description  implied  by  the  term 
"task"  as  it  is  used  in  TSA. 

For  example,  a  set-up  and  check-out  sequence  for  a  piece  of 
equipment  may  involve  ten  different  steps  of  routine  meter  reading  and 
knob  turning.  The  analyst  will  find  that  meaningful  data  cannot  be 
obtained  within  TAM  if  each  of  the  steps  is  treated  as  a  task.  Further¬ 
more,  the  improvement  in  performance  which  is  attributable  to  training 
cannot  be  estimated  for  such  microscopic  units  of  behavior.  Thus,  one 
of  the  necessary  inputs  for  the  TAP  stage  of  TSA  will  be  lacking.  In 
any  case,  if  the  steps  are  indeed  routine,  it  is  the  sequence  of  steps, 
and  not  their  individual  performance,  which  may  derive  benefit  from 
training.  Therefore,  it  is  the  complete  set-up  and  check-out  procedure 
which  should  be  considered  as  a  task. 

To  take  an  opposite  example,  it  would  be  equally  meaningless 
to  define  a  task  such  as  "operates  ECM  receiver"  when  several  major 
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functions  may  be  performed  on  this  piece  of  equipment  (e.g.,  detection, 
signal  localization,  and  classification).  In  obtaining  the  information 
needed  for  TAM,  the  analyst  would  find  that  the  data  he  was  getting  were 
too  general  to  be  of  much  use  in  planning  training.  He  would  soon  see 
that  training  must  be  considered  separately  for  each  of  the  major  functions 
which  can  be  performed  at  the  ECM  receiver,  and  that  each  must  be  con¬ 
sidered  as  a  task. 

Identification  of  tasks  cam  be  done  in  several  ways.  You 
should  select  the  approach  that  best  fits  the  situation  and  system  in 
which  you  are  working.  In  some  cases  your  job  will  be  easier  and  the 
results  better  if  you  start  out  with  a  list  of  positions.  Each  position 
title  cam  then  be  a  focal  point  for  inquiring  about  tasks.  In  other 
cases  identifying  the  tasks  first,  and  then  determining  which  position 
performs  each,  will  be  the  preferable  approach.  If  you  have  previously 
performed  a  System  Block  Analysis,  you  may  already  have  a  good  conception 
of  most  of  the  tasks  which  are  involved.  As  your  informant  was  giving  a 
narrative  description  of  the  typical  operation  of  the  system,  you  were 
probably  jotting  down  units  of  behavior  which  might  be  considered  tasks. 
This  tentative  list  should  now  be  confirmed  with  the  informant  and  any 
gaps  in  the  list  should  be  filled  with  tasks. 

The  final  set  of  tasks  should  be  written  on  the  Task-Time  Chart 
in  the  approximate  order  of  their  occurrence.  Listing  tasks  in  this 
sequence  facilitates  accomplishment  of  some  of  the  other  objectives. 

2.  Determine  Typical  Total  Block  Time 

Having  identified  the  tasks  in  the  block,  you  should  now 
enquire  into  the  amount  of  time  which  typically  elapses  between  the 
beginning  of  the  first  task  and  the  ending  of  the  last  task.  This  in¬ 
formation  is  entered  in  the  heading  of  the  Task-Time  Chart.  If  your 
informant  has  difficulty  in  making  this  estimate ,  you  might  try  ob¬ 
taining  the  information  through  the  method  of  successive  approximation 
described  on  page  ky. 


33 


NAVTRADEVCEN  1218-4 


3«  Determine  Typical  Duration  and  Coordination 
•  Proportional  Duration 


— ' — - - "Sie-ai®  -e-f--thxs--portri-on--oi-  'fche- analysis  is-  to- -obtain -and 

record  estimates  of  how  the  tasks  you  have  identified  fit  into  the  block, 
or  major  operating  stage,  in  terms  of  their  typical  sequence  and  their  typical 
relative  duration.  It  should  be  made  clear  that,  at  this  point  in  TAM, 
there  is  no  need  to  obtain  firm  estimates  of  typical  task  duration  in 
units  of  time.  That  will  come  later  in  the  analysis.  The  current  goals 
should  be  to  depict  task  duration  in  terms  of  the  proportion  of  the  total 
block  time  which  is  occupied  by  each  task  and  to  show  roughly  the 
sequential  interrelationships  among  tasks.  This  is  accomplished  as  follows: 

In  the  "Time  Relationships"  (see  Fig.  4)  section,  draw  a 
horizontal  line  opposite  each  task  name,  beginning  the  line  at  the  pro¬ 
portional  time  point  at  which  the  task  usually  starts,  and  ending  it  at 
the  proportional  time  point  at  which  the  task  usually  ends.  For  example, 
if  a  task  starts  at  the  beginning  of  the  block  and  ends  half  way  through 
the  block,  start  its  line  at  time  0  and  end  it  at  .5.  A  task  that  starts 
3/10  of  the  way  through  the  block  and  ends  8/10  of  the  way  through  would 
have  a  line  from  .3  to  .8.  Figure  4  shows  that  the  "Erect  and  Coarse  Align" 
task  is  performed  twice.  The  missiles  in  the  lower  firing  order  are  typ¬ 
ically  erected  and  coarse  aligned  during  the  first  2/10  of  the  block. 

The  missiles  in  the  higher  firing  order  are  typically  erected  and  coarse 
aligned  during  the  middle  2/10  of  the  block. 

Occasionally  you  will  find  an  informant  who  will  not  be 
able  to  discuss  task  duration  in  terms  of  the  proportion  of  block  time 
it  occupies.  The  informant  will  speak  in  terms  of  minutes,  no  matter  how 
you  try  to  steer  the  conversation  to  proportions.  When  this  situation 


3^ 


NAVTRADEVCEN  1218-4 


is  encountered,  you  should  accept  the  data  in  terms  of  real  time  and, 
from  a  knowledge  of  the  typical  block  time,  compute  your  own  proportions. 
At  the  same  time,  you  will  probably  want  to  jot  down  the  real  time  each, 
proportional  unit  represents.  This  information  will  be  of  use  in  the  PunC' 
tional  Task  Description  stage  of  TAM  which  follows. 

.  Coordination  Requirements 

Whether  any  coordination  or  teamwork  is  involved  in  the 
performance  of  a  task  can  be  determined  by  obtaining  the  answers  to  the 
following  two  questions: 

1.  May  the  task  performer  have  to  modify  what,  how,  or 
when  he  performs  his  task  because  of  the  way  someone 
else  performs  another  task  at  or  near  the  same  time? 

2.  May  someone  else,  performing  a  different  task  at  or 
near  the  same  time,  have  to  modify  what,  how,  or  when 
he  does  it  because  of  the  way  the  performer  of  this 
task  performs  his  task? 

If  the  answer  to  either  of  the  two  questions  above  is  "yes" 
more  information  must  be  obtained.  It  is  necessary  to  determine: 

1.  With  what  other  task  or  tasks  must  the  task  being 
described  be  coordinated? 

2.  What  is  the  nature  of  the  required  coordination? 

The  identification  of  the  related  tasks  is  needed  so  that 
provisions  can  be  made  for  team  practice  during  training,  if  necessary. 

The  nature  of  the  coordination  helps  in  deciding  whether  team  practice 
is  desirable. 
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Coordination  can  be  described  in  two  ways: 

.  Kind  of  coordination 
.  Closeness  of  coordination 


Kinds  of  coordination — Two  kinds  are  defined: 

1.  Physical,  as  when  two  men  work  together  to  lift  an 
object;  or  when  one  holds  test  leads  on  test  points 
and  the  other  reads  the  meter.  Physical!  coordination 
occurs  when  two  task  performers  collaborate  to  achieve 
a  single  immediate  objective. 

2.  Communicational ,  as  when  one  task  performer  must 
provide  information  to  the  other  in  order  to 
achieve  performaince  of  a  task. 

Examples:  co-pilot  calling  out  airspeeds  to  pilot 
during  landing;  rigger  providing  haind 
signals  for  a  crane  operator. 

Closeness  of  coordination — Three  categories  are  defined: 

1.  Start-finish.  Performance  of  a  task  must  await  a 

specified  cue  from  another  task.  For  example,  "start 
engine"  cannot  be  performed  until  after  ground  power 
has  been  plugged  in.  In  some  cases  the  critical 
coordination  is  at  the  finish  of  a  task  instead  of 
at  the  beginning.  That  is,  the  time  at  which  Task  X  is 
started  may  not  be  important,  as  long  as  it  is  finished 
at  the  same  time,  or  before,  Task  Y  is  finished. 

Indicate  start-finish  coordination  with  an  arrow  from  the 
prerequisite  event  to  the  event  for  which  it  is  a  prerequisite.  For 
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example,  if  Task  B  cannot  be  started  until  Task  A  is  finished,  draw  an 
arrow  from  the  event  at  the  finish  of  Task  A  to  the  event  at  the  start 
of  Task  B.  Figure  4  shows  that  "Fine  Alignment"  is  not  begun  until  "Ere^t 
and  Coarse  Align"  is  finished  for  all  of  the  missiles  in  either  the 
higher  or  the  lower  firing  order. 

2.  Discrete  feedback.  Several  interchanges  of  cues  or 
information  are  required  between  two  tasks.  The  in¬ 
formation  passed  back  and  forth  is  discrete;  al though 
the  information  from  one  task  may  affect  the  perfor¬ 
mance  of  another,'  it  will  not  require  continuous 

a  ustment  to  continuously  changing  cues.  Example: 

v  plotter  reports  a  certain  kind  of  target  to  CIC 
officer.  CIC  officer  instructs  plotter  to  assign 
a  certain  weapon  to  that  target,  plotter  makes  the 
assignment,  plotter  reports  assignment  made. 

Indicate  this  kind  of  coordination  by  drawing  a  slant 
line  between  the  middles  of  the  horizontal  lines  representing  two  tasks 
requiring  this  coordination.  Put  an  arrowhead  on  both  ends  of  this 
connecting  line.  The  slant  lines  in  Figure  4  indicate  that  the  Fire  Control 
Supervisor  and  the  two  Fire  Control  Operators  interact  intermittently  during 
performance  of  the  "Erect  and  Coarse  Align"  task-- 

3.  Continuous  feedback.  Performer  of  one  task  gets  a 
continuous  stream  of  cues  from  the  performer  of 
another  task,  and  adjusts  his  performance  accordingly. 
This  need  not  necessarily  go  on  for  the  whole  length 
of  the  task.  Examples:  Crane  operator  responding 

to  signals  from  rigger;  carr. er  pilot  responding  to 
signals  from  landing  officer. 
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Show  continuous  feedback  coordination  by  drawing  a  wavy 
line  between  the  middles  of  the  horizontal  lines  representing  the  two 
tasks  which  must  be  coordinated  in  this  way.  Put  an  arrowhead  on  eacn 
end  of  the  wavy  line.  The  wavy  lines  in  Figure  4  show  that  the  Fire  Control 
Supervisor  and  the  >wo  Fire  Control  Operators  interact  continuously  during 
the  "Fine  Alignment"  task. 

Other  rules  for  showing  coordination: 

1.  If  coordination  is  required  among  more  than  two  tasks, 
draw  as  many  lines  as  necessary  to  show  this  coordina¬ 
tion. 

2.  Put  a  circled  number  on  each  coordination  arrow  for 
which  any  explanation  is  required  and  write  an  explana¬ 
tory  note  on  the  back  of  the  form. 

4.  Determine  Adverse  Conditions  that  Affect  a  Given  Time  Period 


Adverse  conditions  are  the  environmental  or  situational  factors 
which  act  to  degrade  or  disrupt  task  performance.  When  adverse  conditions 
are  present,  the  operator  generally  has  to  put  forth  greater  effort  in  an 
attempt  to  maintain  normal  procedures  or  a  normal  rate  of  performance. 

In  some  cases,  adverse  conditions  will  affect  all  tasks  being 
performed  at  the  time  the  condition  is  present.  Conditions  that  have  the 
same  effect  on  all  tasks  performed  within  that  time  period  shorld  be  recorded 
on  the  back  of  the  Task-Time  Chart  (Fig.  5)*  This  does  not  mean 
that  an  adverse  condition  must  affect  all  tasks  in  the  block  for  it  to 
be  recorded  on  this  form.  It  does  mean  that  all  tasks  being  performed 
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while  the  adverse  condition  is  present  must  be  affected  and  affected  in 
the  same  manner.  Adverse  Conditions  which  are  specific  only  to  some  of 
the  tasks  in  that  time  period,  or  which  affect  the  tasks  in  that  time 
period  with  different  degrees  of  severity,  should  be  recorded  on  the 
Functional  Task  Description  form  described  later. 

Three  kinds  of  adverse  conditions  should  be  reported: 

1.  Environmental  conditions,  such  as  cold,  heat, 
vibration. 

2.  Personal  encumbrances,  such  as  pressure  suit, 
gloves,  oxygen  mask. 

3.  Emotional  factors,  such  as  fear-producing 
situations. 

Often  a  given  adverse  condition  will  exist  every  time  the 
group  of  tasks  in  question  is  performed.  For  example,  escaping  from  a 
submerged  helicopter  will,  by  definition,  always  be  done  under  water. 

In  many  cases,  however,  an  adverse  condition  will  exist  only  part  of  the 
time.  For  example,  if  the  task  were  "escape  from  a  ditched  helicopter," 
the  task  would  have  to  be  done  under  water  only  part  of  the  time.  In 
some  cases  it  would  be  possible  to  get  out  before  the  helicopter  sank. 

Other  adverse  conditions,  such  as  noise  or  vibration,  may 
occur  at  different  levels  of  severity  within  the  time  period  covered  by 
the  block.  Since  the  student  in  training  may  be  able  to  adapt  to  some 
of  those  conditions,  data  on  the  intensity  of  adverse  conditions  are 
required. 
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Often  the  presence  or  absence  of  various  adverse  conditions, 
or  the  severity  of  those  conditions,  will  be  different  each  time  the 
tasks  are  performed.  If  this  is  the  case,  estimates  should  be  obtained 
of  how  often  the  various  degrees  of  severity  are  likely  to  be  present. 

After  you  have  collected  all  the  "adverse  conditions"  data, 
you  will  have  filled  out  a  four-column  table  like  the  one  shown  in 
Figure  5*  The  meaning  of  each  column  and  suggestions  for  obtaining 
the  data  follow  below.  You  are  urged  to  fold  out  Figure  5  and  refer 
to  it  as  you  read  about  the  required  entries. 

Adverse  Condition — What  adverse  condition  are  you  describing? 
The  following  are  some  adverse  conditions: 

Air  degradation:  fumes,  hypoxia 
Crowding 

Encumbrances:  boots,  gloves,  clothing,  headset,  helmet, 
life  jacket,  mask,  personal  armor,  suit 
(pressure ,  G) 

Fear  producers:  startle,  isolation 

G-Forces :  turbulence 

Humidity:  too  high  or  too  low 

Illumination,  glare,  variable 

Noise:  steady,  intermittent,  voice 

Personal  hazards 

Rain,  sleet,  or  snow 

Temperature:  too  high,  low,  varying 

Vibration 

Weightlessness 

Wind 
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SOME  COMMON  ADVERSE  CONDITIONS 

Air  degradation:  fumes,  hypoxia 
Crowding 

Encumbrances:  boots,  gloves,  clothing, 
headset,  helmet,  life  jacket,  mask, 
personal  armor,  suit  (Pressure;  G) 
Fear  producers,  startle,  isolation 
G-Forces:  turbulence 
Humidity:  too  high  or  too  low 
Illumination:  glare,  variable 
Noise:  steady,  intermittent,  voice 
Personal  hazards 

Temperature:  too  high,  low,  varying 

Vibration 

Weightlessness 


Notes: 


(J)  Erec  £  ion  and  coarse  alignment  must  be  comp /etej  before  fine 
aiio>\nient  can  be  begun, 

(2)  Firing  of  f/rsT  mi s  s  «  1  &s  In  either  the  higher  or  the.  lon/er 
firing  order  must  U-IIok  c  omplet'ion  of  f,n  &  aliment 
for  those  rYi  \  S  S  I  I  e  $  , 


Figure  5*  Task-Time  Chart  (Back) 
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Severity — How  severe  is  the  condition?  To  what  extent  will 
it  disrupt  or  degrade  performance?  This  is  very  hard  to  determine  and 
you  will  have  to  rely  heavily  on  the  judgment  of  your  informant*  You 
can  describe  severity  at  three  levels,  as  follows » 

Level  1:  Will  disrupt  performance  of  an  inexperienced 
task  performer.  More  experienced  task  performers  will 
probably  have  learned  to  adapt  to  the  condition*  so 
their  performance  will  be  affected  very  little*  if  any. 

Level  2:  The  condition  is  severe  enough  to  cause 
degradation  of  'performance  of  any  task  performer, 
regardless  of  his  experience. 

Level  3:  The  condition  is  severe  enough  t  .  mako  it 
almost  impossible  to  complete  the  tasks  within  the 
specified  performance  requirements. 

Indicate  the  level  of  severity  by  writing  its  number  in  the 
appropriate  column.  You  may  have  to  list  more  than  one  level  of  severity 
for  some  conditions.  It  is  possible  that  a  condition  may  occur  at  one 
level  sometimes,  and  at  a  different  level  at  other  times.  You  indioste 
the  relative  frequency  of  each  level  of  severity  in  the  next  column  of 
the  table.  Figure  5  (fourth  line)  indicates  that  a  severity  of  cold  which 
would  degrade  the  performance  of  experienced  workers  during  the  first  2/10 
of  the  task  has  a  probability  of  occurrence  of  .05.  It  is  much  more  pro¬ 
bable  (.9)  that  the  cold  will  affect  the  performance  of  inexperienced 
operators  during  this  portion  of  the  block.  (See  second  line.) 

Probability  of  Occurrence — Opposite  each  severity  level  you 
have  listed  for  a  given  condition,  write  a  number  that  indicates  the 
percent  of  time  that  the  adverse  condition  will  have  this  severe  an 
effect  on  performance.  You  can  think  of  it  this  way:  If  the  tasks  art 
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performed  one  hundred  times,  in  how  many  times  out  of  that  hundred  would 
the  first  severity  level  occur?  In  how  many  would  each  of  the  other  levels 
that  you  have  listed  occur?  For  example,  noise  may  occur  at  level 
1,  50  out  of  100  performances;  and  at  level  3,  5  out  of  100.  This  would 
mean  that  this  adverse  condition  would  be  recorded  on  two  separate  lines 
of  the  table. 

Percentage  of  Time  or  Proportional  Limits — If  a  significant 
adverse  condition  does  occur,  it  may  not  last  for  the  whole  time  period 
covered  by  the  Task  Time  Chart.  In  this  last  column  you  can  record  the 
portion  of  the  total  time  which  would  be  affected,  as  follows: 

An  adverse  condition  at  a  given  level  of  severity  which  is 
present  for  only  a  part  of  the  time  period  may  occur: 

a.  Always  during  the  same  part  of  the  time  period 
(predictable) . 

b.  Scattered  across  the  time  neriod  in  an  unpredictable 
manner. 

If  the  part  of  the  time  period  it  will  affect  is  predictable, 
that  is,  if  the  adverse  condition  always  affects  the  same  part,  you  can 
identify  that  part  in  this  column.  For  example,  you  can  indicate  that 
this  particular  adverse  condition,  whenever  it  occurs,  will  affect  the 
time  period  between  .3  and  .7  on  the  time  base  diagram.  Figure  5 
(second  line)  shows  that  the  probability  that  the  performance  of  an 
inexperienced  operator  will  be  degraded  by  the  cold  during  the  first 
2/10  of  the  block  is  .9.  However,  the  probability  that  the  cold  will 
be  that  severe  throughout  the  entire  block  is  only  .35*  (See  third  line.) 

In  the  case  where  the  advex'se  condition  may  occur  at  various 
unpredictable  times ,  it  will  be  useful  to  know  approximately  what  pro¬ 
portion  of  the  time  period  will  usually  be  affected.  In  this  case  you 
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can  indicate,  for  example,  that  when  this  adverse  condition  occurs,  it 
can  be  expected  to  cover  40#  of  the  period,  even  though  you  do  not  know 
which  40#  will  be  affected.  Simply  write  "40#"  in  this  column  instead  of 
the  proportional  limits. 

0.  Preparing  Functional  Task  Descriptions 

The  Task-Time  Chart  just  completed  pertains  to  the  relationships 
between  tasks.  The  Functional  Task  Description  is  aimed  at  describing  the 
activities  within  tasks  and  the  relationships  among  these  activities. 

The  following  five  objectives  are  accomplished  in  the  Functional  Task 
Description  phase  of  TAM: 

1.  Determine  the  Time  Performance  Requirement  and  Typical  Time 
for  the  task. 

2.  Identify  the  kinds  of  activities  in  the  task  and  show  the  time 
relationships  among  them. 

3.  Determine  what  proportion  of  attention  each  activity  requires 
of  the  task  performer. 

4.  Identify  contingencies,  i.e.,  occurrences  that  may  disturb 
normal  performance. 

5.  Identify  adverse  conditions  that  apply  only  to  the  individual 
task. 

This  description  is  recorded  on  the  Functional  Task  Description  form, 
which  is  illustrated  in  Figure  6.  You  are  urged  to  fold  out  Figure  6  and 
refer  to  it  as  you  read  about  how  these  five  objectives  are  to  be  accomplished. 
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FUNCTIONAL,  task  description 


SSRST-  Fir.  MU.il.>  J_ZJ2_ 

(Action  verb  ana  object) 

Time  Performance  Requirement-  "ZOrnmuCei _ 

Position  ! T'C ?.  -C-°  "trot  Super  v  i  $or _ 

Using  Supervisor's  Control  Pane.li  _ 

I ntereem _ 

(Equipment,  tools  or  ether  materials) 


Project _ /OQO. _ 

Typical  Task  Time  / 6  m  i n  uTes 
Informant _ Smith _ 

Analyst  Jo  n  C  S 

Date  &  PjrS.  ... 


Activity 

Percentage 
of  Attention 

Time  Relationships* 

Procedure  Following 

30 

<9 

G) 

Continuous  Perceptual 

Motor  Activity 

0 

Monitoring 

ID 

( 7> 

r?) 

Communicating 

10 

0) 

Decision  Making  or 

Problem  Solving 

SO 

Other  (explain  in  notes) 

0  1 

Non-Task  Related 

Activity 

0 

— 

Proportional  Time  0  .1  2  .3  .4  .5  .6  .7  8  .9  T 


Contingency 

Cue 

Response 

- I 

Frequency 

Reference** 

ttstch  Stu(,k 

Red 

See  Unsched.  Maint. 

.05 

!0.3 

Computer  No-Go 

Red  computer 

Eroded  Re.  Fire 

JO  : 

— 

Computer  S/o-Cic 
Repeat 

Red  COMPUTER 

By  -  Pa  SS 

o 

/OA 

**  If  response  is  complex,  cross-reference  here  to  task  created  by  contingency. 


Adverse  Condition 

Seventy 

Prob.  of 
Occurence 

%  of  Time  or 
Prop.  Limits 

Crowding  in  on  standi  n g  space 

2 

,Z5 

85% 

•Show  initial  and  terminal  Activity  events  on  the  Time  Relationships  chart.  Explain  on  the  back 


Figure  6.  Functional  Task  Description  Form 
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1.  Determine  Time  Performance  Requirement  and  Typical  Task  Time 
.  Time  Performance  Requirement 

The  Time  Performance  Requirement  for  a  task  is  the  maximum 
length  of  time  the  task  performer  could  take  without  his  performance 
being  considered  unacceptable.  It  is  the  worst  level  of  performance  the 
operator  could  display  without  jeopardizing  accomplishment  of  the  system 
mission  within  its  prescribed  limits. 

Most  tasks  must  be  completed  within  a  specified  period 
of  time  if  the  system  of  which  they  are  a  part  is  to  be  effective.  For 
example,  if  operational  requirements  demand  that  a  missile  be  fired 
within  15  minutes  of  the  initial  system  event,  then  no  task  in  the 
countdown  can  take  longer  than  15  minutes.  If  two  tasks  must  be  per¬ 
formed  sequentially  before  the  missile  is  fired,  the  sum  of  their  per¬ 
formance  times  must  not  exceed  15  minutes.  The  number  and  complexity  of 
the  tasks  that  must  precede  or  follow  a  given  task  within  a  time-limited 
seqment  of  system  operation  determines  the  Time  Performance  Requirement 
(TPR)  for  that  task. 

Determining  the  Time  Performance  Requirement  for  a  task  is 
usually  difficult.  You  will  rarely  get  an  immediate  satisfactory  answer 
to  a  direct  question  about  how  much  time  is  available  for  performance  of 
a  task.  The  amount  of  time  available  for  performance  of  a  task  depends 
on  when  preceding  tasks  were  completed,  and  how  much  time  is  taken  in 
performance  of  other  tasks  going  on  at  the  same  time. 

Two  constraints  on  performance  time,  however,  can  be 
helpful  in  determining  the  TPR: 
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a,  Th«  ilia  of  performance  times  of  tasks  that  must  be 
performed  in  sequence,  rather  than  simultaneously, 
cannot  exoeed  the  total  time  period  in  which  the 
tasks  must  be  performed.  In  the  missile  example, 
if  five  tasks  must  be  done  in  sequence  to  launch 
the  missile,  the  total  of  times  for  the  five 
tasks  oaanot  exceed  fifteen  minutes. 

b.  Unless  an  operator  has  concurrent  tasks,  the  total 
of  performance  times  for  tasks  performed  by  one 
person,  regardless  of  the  order  in  which  they 

are  performed,  cannot  exceed  the  total  time  in 
which  the  tasks  must  be  performed.  In  the  missile 
example,  if  an  operator  must  perform  five  tasks, 
the  total  of  times  of  the  five  tasks  cannot 
exceed  fifteen  minutes. 

Application  of  these  two  constraints  will  usually  assist 
vou  in  arriving  at  Time  Performance  Requirements  for  individual  tasks. 

If  your  informant  is  reluctant  to  state  a  TPR,  you  may  be 
able  to  coax  one  out  of  him  by  using  the  following  technique  of 
successive  approximation; 

a.  Seleot  a  time  that  you  guess  mignx  be  a  reason¬ 
able  task  performance  time. 

b.  Ask  your  informant  "Is  the  Time  Performance  Require¬ 
ment  mor®  or  less  than  _  minutes?" 

c.  If  he  says  "more,"  select  a  time  substantially 
longer  than  the  first  one  you  mentioned,  and  ask 
him  if  the  task  can  take  longer  than  this  second 
time  that  you  selected,  without  disrupting  the 
operation  of  the  system. 
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If  he  says  ‘'less'*  to  your  original  question, 
select  a  time  substantially  shorter  than  the 
first  one,  and  ask  him  if  the  task  oust  take  a 
shorter  time  than  the  second  time  you  mention. 


d.  Repeat  this  cycle  sis  often  as  necess ary  to  get 
the  time  estimate  you  need. 


An  exsunple  of  how  you  migh' 

as  follows: 

Your  question 

Can  it  take  longer  than  30  minutes? 

Must  it  take  less  than  10  minutes? 

Csin  it  take  longer  than  20  minutes? 

How  about  25  minutes? 


"zero  in"  on  sm  estimate  is 

Informant’s  answer 

it  has  to  be  done  faster  than  that 
more  than  that  is  all  rignt. 

I  think  so. 

That  sounds  about  right. 


No 

No 


Whenever  possible,  the  TPR  for  a  task  should  be  derived  from 
a  knowledge  of  the  time  constraints  imposed  upon  larger  segments  of  the 
system,  as  described  above.  Occasionally,  however,  this  will  not  be 
possible.  Some  tasks  are  not  affected  by  larger  time  constraints.  In 
the  latter  case,  you  should  base  the  TPR  upon  the  informant's  judgment 
of  a  minimally  acceptable  time  standard,  in  terms  of  what  a  supervisor 
might  consider  acceptable.  A  question  such  as  "What  is  the  slowest  the 
operator  could  perform  this  task  without  getting  chewed  out?"  might 
serve.  Whenever  some  figure  other  than  a  system-imposed  TPR  is  recorded, 
this  fact  should  be  noted  beside  the  entry  on  the  form. 


.  Typical  Task  Time 

Typical  Task  Time  can  be  estimated  by  studying  the  behavioral 
content  of  the  task  and  comparing  the  task  in  question  with  similar  tasks 
within  your  experience  or  the  experience  of  your  informant.  The  behavioral 
content  of  the  task  will  be  identified  in  completing  the  other  items  of 
the  Functional  Task  Description. 
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Typical  Task  Time  can  also  be  determined  by  asking  your 
informant  what  he  thinks  it  is.  Your  informant  may  occasionally  have  a 
tendency  to  give  the  same  estimate  for  the  Time  Performance  Requirement 
and  the  Typical  Task  Time.  For  the  vast  majority  of  tasks,  however, 
these  two  estimates  should  not  be  the  same.  Be  sure  to  ask  for  the 
Time  Performance  Requirement  before  asking  for  the  Typical  Task  Time. 

If  the  two  estimates  turn  out  to  be  the  same,  make  sure  that  your  infor¬ 
mant  has  grasped  the  difference  between  the  two  concepts  and  ask  again 
whether  the  two  times  should  really  be  the  same. 

If  your  informant  has  difficulty  in  estimating  Typical 
Task  Time,  the  technique  of  successive  approximation  suggested  for 
obtaining  Time  Performance  Requirements  might  again  prove  useful. 

A  few  tasks  with  significant  amounts  of  monitoring 
behavior  will  create  problems  for  the  estimation  of  both  Typical  Task 
Time  and  Time  Performance  Requirement.  When  tasks  consist  primarily  of 
monitoring,  the  time  devoted  to  monitoring  is  often  highly  variable.  It 
is  greatly  dependent  upon  the  frequency  of  the  event- to-be-detected.  For 
such  tasks,  the  Typical  Task  Time  and  the  Time  Performance  Requirement 
will  have  to  be  based  upon  the  time  from  the  occurrence  of  the  event-to-be- 
detected  to  the  completion  of  the  task.  The  time  devoted  to  monitoring 
will  have  to  be  completely  excluded.  When  this  is  done,  it  should  be  noted 
on  the  form. 

2.  Identify  Activities  in  the  Task  and  Show  Their  Time 
Relationships  '  '  '  '  "  ' 

Tasks  can  be  described  in  terms  of  six  types  of  activities. 

Each  type  has  associated  with  it  certain  functional  training  requirements. 
If  it  is  known  that  a  task  contains  one  of  these  types  of  activity,  the 
kind  of  training  required  to  bring  about  learning  of  that  part  of  the 
task  can  be  specified. 
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Some  tasks  may  contain  only  one  activity.  Others  may  contain 
several.  In  some  tasks,  the  activities  may  always  be  performed  in  the 
same  order.  In  others  the  order  may  be  widely  variable. 

The  following  six  classes  of  activity  are  defined  in  TAM: 

1.  Procedure  Following 

2.  Continuous  Perceptual-Motor  Activity 

3.  Monitoring 

4.  Communicating 

5.  Decision  Making  and  Problem  Solving 

6.  Non-Task-Related  Activity 

Occasionally  you  may  find  a  task  that  contains  an  activity 
which  does  not  clearly  fall  into  one  of  the  basic  six  types  defined 
below.  This  can  be  indicated  by  assigning  some  percentage  of  attention 
to  the  category  labelled  "other"  and  describing  that  activity  under 
Notes.  However,  the  purposes  of  this  task  analysis  procedure  will  be 
best  served  if  you  use  the  "other"  category  sparingly. 

Procedure  Fo^uwing — Performing  a  sequence  of  discrete  steps, 
each  of  which  has  an  identifiable  beginning  point  and  ending  point. 

Six  kinds  of  steps  are  listed  below;  there  are  others. 

a.  Setting  r.  control  to  a  single  specified  position. 

b.  Reading  a  display. 

c.  Observing  a  display  reaction  and  operating  a  control 
to  set  the  display  to  a  certain  point. 

d.  Fastening  or  unfastening  a  connector  or  fastener. 

e.  Putting  an  object  into  position  or  removing  it  from 
position. 

f.  Obtaining  an  item  of  information  from  a  reference 
document . 
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Examples  of  Procedure  Following: 

a.  Performing  a  daily  operating  check  on  a  radar  set. 

b.  Performing  an  aircraft  pre-flight  check. 

c.  Replacing  a  defective  electronic  component. 

d.  Typing. 

Routine  manipulative  behavior  is  generally  classed  as  Procedure 
Following  because  the  operator  is  usually  following  a  set  procedure. 

Most  often  the  procedure  has  been  committed  to  memory,  but  sometimes  it 
is  present  in  the  form  of  a  performance  aid.  The  procedure  may  be 
either  fixed  or  branched.  A  branched  procedure  is  one  in  which  th-  step 
to  be  taken  at  one  or  more  points  is  governed  by  the  result  of  a  percep¬ 
tion  or  discrimination. 

Even  though  a  finger  may  have  to  be  "aimed”  at  a  button  or  a 
screw  driver  "aimed"  at  a  screw,  such  behaviors  should  be  classed  under 
Procedure  Following  rather  than  under  Continuous  Perceptual-Motor 
Activity,  in  that  there  need  be  no  continuous  compensation  for  movement 
of  the  "target."  Similarly,  "hooking"  a  target  on  a  radar  display  with 
a  stylus  should  be  classed  as  Procedure  Following  activity.  The  operator 
usually  does  not  have  to  compensate  for  target  movement  while  hooking  it. 
The  target  does  not  move  for  one  full  sweep  of  the  radar  antenna. 

Continuous  Perceptual-Motor  Activity — Observing  displays  and 
operating  controls  continuously  in  order  to  maintain  a  specified  relp '..ion- 
ship  between  an  object  under  the  operator's  control  and  other  objects,  not 
under  the  operator's  control.  This  activity  is  commonly  called  tracking. 
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Examples  of  Continuous  Perceptual-Motor  Activity: 

a.  Guiding  a  vehicle  in  which  the  operator  is  riding. 

b.  Operating  remote  manipulators,  including  such  diverse 
things  as  remote  hands  and  hoisting  cranes  or  draglines. 

c.  Keeping  a  cursor  on  a  target;  either  pursuit  or  com¬ 
pensatory  tracking. 

When  performing  CPMA  the  operator  is  getting  a  continuous 
stream  of  cues  as  to  the  position  of  the  target  (or  object  which  he  does 
not  control)  and  continuous  feedback  as  to  the  position  of  the  object 
that  he  can  control. 

Monitoring — Observing  a  display,  or  a  portion  of  the  environment, 
either  continuously  or  by  scanning,  in  order  to  detect  a  specified  kind 
of  change. 


Examples  of  Monitoring: 

a.  Keeping  watch  for  targets  on  a  radar  scope. 

b.  Watching  engine  gauges  aboard  ship  in  order  to  be 
able  to  forestall  unsafe  conditions. 

c.  Scanning  the  horizon  for  ships. 

d.  Watching  for  indications  of  malfunction  during  a 
missile  countdown. 

e.  Listening  for  unusual  sounds  in  an  engine. 

Notice  that  the  simple  act  of  attending  to  a  display  does 
not  constitute  Monitoring,  even  though  displays  are  often  monitored. 
Reading  a  display  is  most  often  a  step  in  Procedure  Following.  The  con¬ 
cept  of  Monitoring  within  TAM  involves  prolonged  or  periodic  watchfulness 
to  detect  a  specific  class  of  cues  or  an  environmental  change.  The 
moment  of  occurrence  of  this  change  is  often  not  predictable. 
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Communicating — Receiving  information  and/or  sending  information 
either  in  vords  or  in  other  kinds  of  symbols. 

Examples  of  Communicating: 

a.  GCA  operator  "talking  down"  pilots. 

b.  Radio  operator  receiving  or  sending  messages. 

c.  A  commander  giving  orders  to  subordinates. 

Decision  Making  or  Problem  Solving — Decision  Making  consists 
of  choosing  a  course  of  action  on  the  basis  of  facts,  opinions,  and 
other  information  relevant  to  the  decision.  Problem  Solving  is  a  broad 
category  of  purposeful  or  goal-directed  thinking  which  includes  Decision 
Making. 


Examples  of  Decision  Making  or  Problem  Solving: 

a.  Troubleshooting. 

b.  Analyzing  targets  on  a  plot  and  assigning  weapons. 

c.  Figuring  out  how  to  repair  something  with  available 
materials . 

Decision  Making  generally  involves  careful  evaluation  of 
severed  alternative  courses  of  action,  on  the  basis  of  how  well  each 
alternative  serves  the  purposes  of  the  decision  maker.  However,  there 
is  a  class  of  decision-making  activity  in  which  only  one  course  of  action 
is  considered.  When  an  operator  makes  a  "snap"  decision  on  the  basis  of 
a  rule-of-thumb,  special  knowledge  or  experience,  or  memory  of  what 
action  has  proven  successful  in  the  past,  he  is  still  making  a  decision, 
so  long  as  he  could  have  chosen  to  do  something  else  or  to  do  nothing 
about  the  situation.  This  class  of  decision  should  not  be  confused  with 
following  a  branched  procedure.  You  must  distinguish  between  the 
situation  in  which  the  operator  must  follow  an  existing  rule  (as  in 
branched  Procedure  Following)  and  the  situation  in  which  the  operator  is 
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free  to  choose  any  of  several  alternatives  but  acts  as  if  his  choice 
were  determined  by  a  rule,  To  illustrate  the  latter  case:  as  soon  as 
an  unknown  aircraft  appears,  a  weapons  controller  orders  an  intercept 
without  checking  the  availability  of  interceptors  of  the  status  of  his 
ground-to-air  missiles. 

Non-Task-Related  Activity — Activities  which  occupy  the  operator's 
attention  but  do  not  contribute  directly  to  the  accomplishment  of  the  task. 
Many  tasks  do  not  require  the  full  attention  of  the  operator  throughout 
the  performance  of  the  task.  In  such  cases  the  attention-paying  capa¬ 
bility  that  is  "left  over"  from  the  amount  of  attention  required  by  the 
task  may  be  said  to  be  given  to  Non-Task-Related  Activity. 

Non-Task-Related  Activity  may  be  of  two  types: 

1.  Activity  which  is  not  related  to  the  task  being 
analyzed  but  which  is  related  to  some  previous, 
concurrent,  or  future  system  task. 

2.  Activity  which  is  related  to  no  task  in  the  system. 

Examples  of  Non-Task-Related  Activity: 

a.  Chatting  with  fellow  workers. 

b.  Thinking  about  some  other  task  to  be  performed. 

c.  Thinking  about  personal  matters. 

.  Steps  in  Depicting  Task  Activities 

You  will  have  to  adjust  the  specifics  of  your  approach 
to  the  particular  task  and  situation  in  which  you  are  working.  The 
following  steps,  however,  should  guide  your  efforts. 
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Step  1 — Determine  the  type  or  types  of  activities  which 
the  task  performer  should  undertake  at  the  start  of  the  task.  Opposite 
the  first  activity  draw  a  horizontal  line  from  the  left-hand  margin  of 
the  diagram  to  the  point  where  the  activity  ends.  An  activity  may 
occupy  several  periods  within  the  task.  The  length  of  this  line  should 
show- < what  portion  of  task  time  is  normally  or  typically  spent  on  this 
kind  of  activity. 

For  example,  if  the  task  performer  pays  attention  to 
Decision  Making  or  Problem  Solving  throughout  the  entire  task,  the  line 

should  extend  from  0  to  the'  end,  as  shown  in  Figure  6. 

* 

If  a  given  activity  occurs  repeatedly  within  u  certain 
time  segment,  and  if  the  precise  time  at  which  it  occurs  is  variable, 
draw  a  dashed  line  beside  the  name  of  the  activity.  Figure  6  shows 
that  the  task  performer  must  devote  intermittent  attention  to  Communica¬ 
ting  during  the  last  6/10  of  the  task. 

Step  2— Determine  the  reason  that  the  first  kind  of 
activity  is  stopped  and  another  type  started  in  the  task.  Indicate  the 
stopping  of  one  activity  and  the  starting  of  another  with  a  circled 
number,  as  shown  in  Figure  6,  An  activity  may  stop  without  another 
starting  immediately,  leaving  a  gap  in  activity  (see  Procedure 
Following  and  Monitoring,  Figure  6),  This  may  mean  that  attention  to 
the  other  activities  is  intensified  during  that  time  or  that  more 
attention  is  devoted  to  Non-Task-Helated  Activity. 

Explain  the  circled  number  on  the  back  of  the  form, 

under  "notes," 


Step  3— Draw  a  line  opposite  the  second  activity  to  show 
the  portion  of  the  tusk  during  which  this  activity  typically  occurs. 
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Step  4 — Determine  the  reason  that  the  second  activity 
is  stopped  and  another  started  or  intensified.  Indicate  with  a  circled 
number  and  explain  as  before. 

Step  3 — Repeat  any  of  these  steps  as  necessary  to  show 
all  of  the  activities  in  the  task. 

If  your  informant  cannot  express  the  amount  of  time 
typically  devoted  to  an  activity  in  terms  of  the  proportion  of  task 
time  it  occupies,  accept  his  real-time  estimates  and  compute  proportions 
from  your  knowledge  of  typical  task  time.  Note  the  read  time  units 
below  the  proportional  Time  Relationships  scale. 

3.  Determine  the  Percentage  of  Attention  Devoted  to  Each  Activity 

Whenever  a  task  is  performed,  some  of  the  activities  which 
have  been  defined  may  require  a  large  percentage  of  attention.  Others 
may  require  very  little.  If  an  action  must  be  performed  quickly  and 
accurately,  or  if  the  adverse  consequences  of  not  paying  close  attention 
to  some  activity  are  great,  the  task  performer  may  have  to  concentrate 
very  intently  upon  that  single  activity.  At  other  times  he  may  have  to 
divide  his  attention  among  several  activities  at  one  time.  For  example, 
an  operator  may  have  to  monitor  a  radar  screen  and  communicate  with  his 
superior  at  the  same  time. 

Notice  that  we  are  talking  here  about  percentage  of  attention, 
not  time.  The  relative  amount  of  time  an  activity  requires  has  already 
been  presented.  The  amount  of  time  spent  in  an  activity  is  not  neces¬ 
sarily  related  to  the  amount  of  attention  it  demands.  It  is  possible 
to  do  two  different  activities  at  the  same  time  but  it  is  not  possible 
to  devote  full  attention  to  both  at  the  same  time. 
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When  you  introduce  the  topic  of  percentage  of  attention  to  am 
informant  for  the  first  time,  you  should  attempt  to  convey  some  of  the 
above  ideas  to  him.  If  he  has  difficulty  with  the  concept  of  "attention.'1 
you  may  want  to  say,  "Attention  has  to  do  with  how  much  an  operator  has  %•. 
think  about  what  he  is  doing  while  he  is  doing  it,  versus  how  well  he  can 
do  it  automatically,  without  thinking  about  it."  In  asking  for  estimates 
of  percentage  of  attention  you  may  want  to  use  different  terms.  You 
could  ask,  "How  do  the  activities  compare  as  to  the  amount  of  concentra¬ 
tion  or  mental  effort  they  take?" 

Before  you  try  to  obtain  an  estimate  of  percentage  of  attention 
from  your  informant,  be  sure  you  list  for  him  again  all  of  the  activities 
in  the  task.  If  you  simply  ask,  "What  percentage  of  attention  does  the 
operator  typically  give  to  Communicating,"  you  may  get  the  answer,  "When 
he  is  communicating  he  is  giving  all  of  his  attention  to  it."  This  is 
not  the  information  you  want.  You  are  interested  in  apportioning  atten¬ 
tion  among  activities  for  an  entire  task  perf ormance ;  not  for  just  a  piece 
-  '  cl  it. 

-X 

One  way  of  making  these  estimates  is  to  judge,  first,  how  much 
of  the  operator's  attention  will  be  occupied  by  the  task  and  how  much 
will  be  devoted  to  non- task-related  activities.  Then  the  total  percentage 
of  attention  devoted  to  the  tssk  can  be  divided  among  the  remaining  six 
classes  of  activity.  Record  the  percentages  for  both  task-relevant  and 
non-task-related  activities  in  the  "Percentage  of  Attention"  column  on 
the  form. 


It  was  mentioned  that  Non-Task-Related  Activity  may  pertain  to 
activity  related  to  other  system  tasks  assigned  to  the  operator  or  it 
may  not  relate  to  any  tasks  in  the  system.  Inquiry  into  NTRA  of  the 
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second  type  should  be  handled  tactfully.  If  your  informant  is  an 
operational  supervisor,  he  may  be  sensitive  to  the  slightest  suggestion 
that  his  operators  ever  pay  attention  to  matters  which  are  not  related 
to  the  task  they  are  performing. 

4.  Identify  Contingencies 

Contingencies  sire  events  that  cause  disruption  of  any  of  the 
"normal"  sequences  of  task  performance. 

We  know,  in  advance,  that  contingencies  will  oeour  in  almost 
every  task.  We  also  know  that,  in  most  cases,  the  training  program  will 
have  to  include  some  training  cn  how  to  handle  contingencies.  The  task 
analyst's  job  is  to  identify  a  reasonable  sample  of  contingencies  for 
inclusion  in  training;  not  to  determine  whether  contingencies  will  occur. 
The  data  on  contingencies  are  entered  in  the  space  provided  on  the 
Functional  Task  Description  form. 

Kinds  of  Contingencies 

Contingencies  are  of  four  general  kinds: 

1.  Equipment  malfunction. 

2.  Human  error. 

3 I  Unusual  situation  occurring  external  to  the  system 
that  affects  task  performance. 

4.  No  identifiable  cause,  but  something  didn't  work  the 
way  it  was  supposed  to,  or  something  unusual  happened. 

Equipment  malfunction  is  perhaps  the  commonest  type  of 
contingency.  Faulty  operation  of  an  item  of  equipment,  or  the  occurrence 
of  an  out-of-tolerance  indication  usually  requires  modification  in 
performance  of  the  task. 
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Human  error  includes  errors  made  either  by  the  performer 
of  the  task  being  analyzed  or  by  someone  else  upon  whom  normal  perfor¬ 
mance  of  that  task  depends  in  some  way. 

Unusual  situations  are  defined  as  contingencies  that  are 
caused  outside  the  system,  but  which  affect  performance  of  tasks  within 
the  system.  For  example,  the  appearance  of  more  targets  than  a  certain 
tracking  system  can  handle  is  such  a  contingency. 

No  identifiable  cause  contingencies  are  chance  variations 
in  system  performance  which  disrupt  performance  but  whose  cause  is  not 
immediately  apparent.  For  example,  one  such  contingency  associated  with 
the  task  of  escaping  from  a  ditched  helicopter  is  that  the  helicopter, 
as  it  sinks,  may  tip  so  that  the  door  is  on  the  bottom,  making  it 
impossible  to  open  the  door.  The  trapped  men  may  not  know  whether  the 
latch  is  jammed,  the  frame  is  warped,  or  the  air  and  water  pressure  on 
the  hatch  are  unbalanced. 

.  Identifying  a  Sample  of  Contingencies 

The  task  description  should  contain  only  those  contingen¬ 
cies  that  make  a  significant  difference  in  the  way  the  task  should  be 
performed.  Record  those  contingencies  which,  if  improperly  handled  dur¬ 
ing  performance  of  the  task: 

a.  Can  prevent  the  system  from  attaining  its  mission 
within  the  required  time  or  accuracy,  or 

b.  Can  result  in  personal  injury  or  significant 
equipment  damage,  or 

c.  Occur  more  than  20%  of  the  times  the  task  is 
performed. 
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Notice  that  a  contingency  with  any  one  of  these  attributes  is  significant 
and  should  be  reported. 

Contingencies  which  have  no  significant  effect  on  task 
performance,  or  which  the  student  cam  be  expected  to  handle  adequately 
on  the  basis  of  his  general  experience ,  should  be  omitted.  For  example, 
one  contingency  might  be  that  a  control  knob  becomes  loose  and  falls  off 
the  front  of  a  piece  of  electronic  equipment.  Presumably  the  control  can 
still  be  operated  by  grasping  the  shaft  the  knob  was  on,  and  you  would 
expect  that  most  task  performers  would  be  able  to  cope  with  that  con¬ 
tingency  without  amy  speciad  training.  Consequently,  a  contingency  of 
this  kind  should  not  be  included  in  the  taLsk  description. 

The  good  judgment  of  the  task  analyst  and  his  informant  are 
about  the  only  meains  for  deciding  whether  a  contingency  is  significant 
enough  to  include  in  the  task  amalysis.  If  you  judge  that  speciail 
provisions  will  haV^~to  beTHSe  in  tradning  so  the  students  can  learn 
to  handle  a  contingency  adequately,  then  that  contingency  should  be 
included  in  the  sample.  Keep  in  mind  that  contingencies  selected 
strictly  on  the  basis  of  frequency  would  exclude  critical  contingencies 
that  seldom  occur.  On  the  other  hand,  contingencies  selected  only  on 
criticality  would  exclude  the  easily-mamaged  but  frequent  contingencies 
whose  very  frequency  of  occurrence  may  cause  a  disruption  of  normal 
task  performance. 

Judgment  is  especially  required  in  distinguishing  between 
the  contingency  which  is  significant  because  it  is  frequent  (c,  above) 
and  the  event  which  is  frequent  but  is  handled  by  normal  procedures 
aind,  therefore,  is  not  a  contingency.  In  cames  where  this  line  between 
contingency  and  non- contingency  is  difficult  to  determine,  you  will 
have  to  fall  back  on  the  other  two  criteria  (a  and  b) .  If  the  frequent 
event,  when  mishandled,  cam  cause  a  dangerous  condition  or  cam  prevent 
the  system  from  operating  within  acceptable  tolerances  (either  from  a 
single  occurrence  of  the  event  or  from  the  sheer  weight  of  its  frequency), 
that  event  should  be  listed  as  a  contingency. 
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Kinds  of  Information  Wanted 


Three  kinds  of  information  about  contingencies  are  use¬ 
ful  in  making  training  decisions: 

1.  How  is  the  occurrence  of  the  contingency  made 
known  to  the  task  performer? 

2.  How  should  he  respond  to  it? 

3.  How  often  is  it  likely  to  occur? 

How  is  the  occurrence  of  the  contingency  made  known  to 
the  task  performer? — Contingencies  are  usually  made  knovta  to  the  task 
performer  when  he  perceives  that  something  is  happening  that  deviates 
from  "the  book."  That  is,  something  happens  that  is  different  from 
what  he  can  reasonably  expect  it  to  be.  Some  examples  ere:  landing 
gear  does  not  move  when  pilot  puts  the  gear  level  in  "down"  position 
from  "up"  position;  someone  notices  a  torpedo  in  the  "armed"  condition 
in  its  storage  rack;  a  crypto  message  is  received  that  is  not  decodable 
with  the  code  thought  to  be  in  use. 

Note  that  these  contingencies  could  have  been  of  three 
different  kinds.  The  first  could  reasonably  have  been  an  equipment 
malfunction,  the  second  a  human  error,  and  the  third  an  unusual  situation 
from  outside  the  system.  The  important  information  for  training  decisions 
is  how  was  its  presence  made  known  to  the  task  performer— not  what  was 
the  basic  cause  of  the  contingency. 

Considering  the  first  example,  let  us  assume  that  the 
task  is  "landing  the  aircraft."  From  the  standpoint  of  training  the 
pilot'  to  handle  this  contingency,  the  precise  cause  of  the  landing 
gear’s  failure  to  move  is  not  important.  The  way  the  malfunction 
contingency  came  to  the  attention  of  the  pilot  is  important.  Similarly 
with  all  the  other  examples. 
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It  is*true  that  tha  way  the  task  performer  finally  handles 
the  contingency  say  depend  upon  the  cause .  In  the  ease  of  the  landing 
gear  failure,  he  might  do  one  thing  if  the  cause  were  a  popped  circuit 
breaker  and  something  else  if  he  had  lost  hydraulic  pressure.  Ifcit  the 
contingency,  as  the  task  performer  first  sees  it,  is  the  failure  of  the 
landing  gear  to  move.  Anything  he  does  after  that  moment,  such  as 
checking  the  circuit  breakers  or  the  pressure  guage,  is  done  in  response 
to  the  contingency.  It  is  the  responses  to  this  first  cue  that  must  be 
learned  in  training.  This  is  why  the  first  item  of  information  needed 
about  contingencies  is:  how  the  task  performer  becomes  aware  of  them. 

How  should  he  respond  to  it1?— The  task  performer  can  make 
three  different  kinds  of  responses  to  contingencies.  These  are: 

1.  Switch  to  an  alternate  sequence  of  activities. 

2.  Continue  to  perform  the  task  as  well  as  circum¬ 
stances  will  permit. 

3.  Inform  a  superior  and  suspend  further  attempts  to 
perform  the  task  in  question. 

The  response,  or  combination  of  responses,  appropriate 
for  each  contingency  is  information  needed  for  setting  up  requirements 
for  measurement,  feedback,  and  scoring  in  training.  You  should  record 
the  response  which  is  typically  appropriate  for  each  contingency.  Do 
not  merely  classify  each  response  as  one  of  the  above  kinds. 

How  often  is  It  likely  to  occur?— The  information  wanted 
here  is  the  number  of  times  each  contingency  can  be  expected  to  occur 
in  100  performances  of  the  task.  If  necessary,  you  can  again  use  the 
successive  approximation  technique  suggested  for  obtaining  estimates 
of  task  performance  times,  in  order  to  get  frequency  estimates  from 
your  informants. 
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*  Obtaining  Oita  on  Contingencies 

The  major  problem  the  taak  analyst  has  in  obtaining  data 
on  contingencies  la  that  the  system  experts  who  will  provide  the  data 
often  do  not  think  in  terms  of  what  can  go  wrong  with  system  performance. 
The  task  analyst  has  to  prod  them  into  thinking  these  unpleasant  thoughts, 
and  has  to  probe  for  the  needed  information. 

If,  in  interviewing,  you  focus  the  attention  of  the 
informant  on  one  topic  at  a  time,  you  are  likely  to  get  more  accurate 
and  more  complete  information  than  if  you  ask  broad  questions.  This 
focusing  technique  is  useful  in  getting  information  about  contingencies. 

Keep  in  mind  that  you  have  twelve  categories  in  which  you 
can  ask  about  contingencies,  as  shown  in  Figure  7.  You  can  focus  your 
informant's  attention  on  each  of  these  twelve  categories,  one  at  a 
time,  in  order  to  get  reasonably  good  data  on  contingencies. 


Frequent 

Prevent  Mission 
Accomplishment 

Cause  Injury 
or  Damage 

Equipment  Malfunction 

Human  Error 

Unusual  Situation 

No  Known  Cause 

Figure  7.  Categories  for  Focusing  Questions 
about  Contingencies. 

5.  Identify  Adverse  Conditions  That  Apply  Only  to  One  Task 


This  is  done  the  same  way  that  adverse  conditions  were 
identified  for  blocks  of  tasks  on  the  Task-Time  Chart.  The  only  differ¬ 
ence  is  that  the  proportions  and  probabilities  apply  to  the  individual 
task  instead  of  to  a  block  of  tasks. 
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You  may  occasionally  run  across  an  occurrence  which  does  not 
fall  cleanly  into  either  the  "contingency"  or  the  "adverse  condition" 
category.  The  distinction  between  the  two  categories  is  as  follows: 

•  Contingencies  are  task-related  occurrences  which  require 
that  "normal"  procedures  be  modified. 

•  Adverse  conditions  sire  environmental-situational  states 
through  which  the  operator  attempts  to  maintain  normal 
procedures  and  a  normal  rate  of  performance  by  putting 
out  greater  effort. 

They  are  both  factors  which  increase  task  difficulty.  If  you  find  sin 
aspect  of  the  task  which  has  properties  of  both  adverse  conditions  and 
contingencies,  you  should  record  it  under  both  headings  on  the  form. 

E.  Preparing  Behavioral  Details  Descriptions 

This  stage  of  the  analysis  results  in  information  at  the  finest 
level  of  detail  required  in  the  task  description.  As  in  the  previous 
parts  of  the  analysis,  obtaining  appropriate  information  in  this  stage 
depends  heavily  upon  the  judgment  of  the  analyst.  The  information  ob¬ 
tained  in  this  stage  of  the  analysis  will  be  used  for  estimating  the 
capability  of  input  trainees  to  perform  the  tasks,  for  estimating  the 
difficulty  of  the  training  problem  associated  with  each  task,  and  for 
estimating  the  level  of  performance  that  can  be  expected  after  training. 

Obviously,  information  should  be  collected  only  for  those  activi¬ 
ties  present  in  the  task.  While  the  report  form  (see  foldout  Figure  8) 
is  organized  to  keep  your  writing  to  a  minimum,  it  may  be  necessary  for 
you  to  write  some  descriptive  statements  in  order  to  convey  an  accurate 
picture  of  the  nature  of  the  behaviors  involved  in  these  tasks.  Use 
footnotes  freely.  Wherever  a  sentence  will  give  a  more  accurate  picture 
than  check  marks  or  numbers,  use  it. 
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BEHAVIORAL  OETAILS  DESCRIPTION 


BLOCK  NO. 


2JL 


TASK  NO 


..  7.7.  _ 


Number  of  SB  steps  .  _  _2_ 


Procedure  Following 

A^Fixed  -  Number  of  steps  in  procedure _ 2-  O— . 

Branched  —  Maximum  number  of  steps  in  procedure.. 

Describe  below  the  kinds  of  SB  steps  involved: 

# 

Tf  Computer  lights  red  ahter  Erase  and  Re Firel  estimates  needle 
flue  tuition* 


_  Number  oi  possible  steps  which  are  SB ... 


Continuous  Perceptual-Motor  Activity 


lyi* 

_ Guiding  a  vehicle 

_ Operating  remote 

manipulators 
..Keeping  cursor  on 
target 

_ Other _ 


None 

Displays 

.  ..Direct  or  window  view 
...JScope  or  instruments 
_  Optical  system 
_ Other.  _ 

Error  tolerance  or 
accuracy  required: _ 


Controls 

_ Steering  wheel 

_ Track  jig  handle 

_ Handwheels 

_ Other _ 


Control-Display 

Relationship 

_ Position  control 

_ Velocity  control 

_ Acceleration  control 

—  Lag 

_ .Backlash 

_ Other _ 


Monitoring 


Object  or  signal  to  be  monitored: _ Q±&.pJ.d.y„ _ PdJOd  l  .  LjgJxXS. _  _ 


Display 
— Scope 

_ Window  view 

Jr^Instruments 
__Optical  system 

_ Sounds 

_ Qthtf  . 


Relevant  Attribute 

_ Movement  of  object  or 

signal 

_ Appearance  of  object  or 

signal 

VXhange  in  object  or 
signal 

_ Other _ 


Other.  Data 

Estimated  frequency  of  evenis: 
Search  area: _ _ _ _ 


Are  events  easy  to  detect? 

If  ''no*',  how  should  detection  be  made? 


Communicating 

V^Radio  or  telephone 

_ Direct  verbal 

_ Direct  observation 

_ Written  or  printed 

English 


Media 


_ Video 

._  Electro  mechanical 
displays 

...Other _ _ _ 


Special  Knowledge  Requirements 
. .  Code  ...Format 

_ Keyboard  ope-ation 

_ Operation  of  special  equipment 

(Specify) 


Decision  Making  and  Problem  Solving 

_ The  operator  considers  only  one  of  several  available  courses  of  action.  He  bases  his  action  on  a 

rule-of-thumb,  special  knowledge  or  experience,  or  memory  of  what  action  has  proven  successful  in  the  past. 

_ Reasonable  alternatives  are  generated,  considered,  and  rejected,  until  an  acceptable  one  is  found. 

V^Most  possible  alternatives  are  known  by  the  decision  maker  or  problem  solver,  and  all  reasonable  ones  are 
evaluated. 

Describe  what  the  decisions  or  problems  consist  of  and  the  kinds  of  information  used  in  reaching  the  decision  or  solution;. 

signal  flow  Through  parallel  Select  and  Target 
channels, 

Figure  8.  Behavioral  Details  Description  Form 
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Keep  in  mind  that  the  purpose  of  this  part  of  the  analysis  is  to 
fill  in  the  details  to  supplement  all  the  information  you  have  already 
recorded  in  the  previous  stages.  Do  not  repeat  information  just  to 
"fill  in  the  form." 

The  information  is  to  be  recorded  on  the  Behavioral  Details  Des¬ 
cription  form.  If  you  need  additional  space  for  your  notes,  attach 
separate  sheets. 

Many  of  the  items  on  this  form  are  self-explanatory  or  have  been 
explained  in  the  preceding  pages.  The  following  comments  sire  intended 
to  clarify  the  remaining  items. 

1.  Procedure  Following 

Fixed  or  Branched — In  a  fixed  procedure  each  step  is  the  same 
each  time  the  task  is  performed,  regardless  of  the  outcome  of  siny  previous 
steps.  In  a  branched  procedure  the  step  performed  at  one  or  more  points 
in  the  procedure  depends  upon  the  outcome  of  a  previous  step.  If-  we 
consider  an  operator  of  a  piece  of  electronic  equipment,  his  turn-on 
procedure  is  generally  fixed,  while  his  check  and  adjustment  procedure 
is  usually  branched.  The  results  of  each  check  determine  the  adjustments 
to  be  made  and  may  determine  the  subsequent  checks  to  be  made.  The  fact 
that  the  procedure  is  identical  each  time  when  the  equipment  is  in  perfect 
adjustment  does  not  make  it  a  fixed  procedure. 

Enter  a  check  mark  beside  the  word  "fixed"  or  the  word 
"branched"  and  answer  the  questions  to  the  right  of  your  check. 

Number  of  Steps  and  Maximum  Number  of  Steps— A  fixed  pro¬ 
cedure  has  a  fixed  number  of  steps  but  the  number  of  steps  in  a  branched 
procedure  can  vary,  depending  upon  the  outcome  of  some  of  the  steps. 

Some  of  the  branches  may  be  longer  than  others.  For  fixed  procedures 
you  will  indicate  the  number  of  steps,  but  for  branched  procedures  you 
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will  record  the  nwxi mum  number  of  steps*  The  ma-H im»m  number  of  steps 
refers  to  the  longest  path  through  the  procedure,  in  terms  of  steps, 
from  the  beginning  to  the  end  of  the  procedure. 

In  arriving  at  these  figures,  keep  in  mind  that  a  step  gener¬ 
ally  involves  a  single  control  manipulation  or  a  single  display  reading. 
Written  ''step-by-step"  procedures  that  you  may  refer  to  may  not  be 
broken  down  this  finely.  One  "step"  in  a  written  check  procedure,  for 
example,  may  be  "Turn  on  the  system."  This  "step"  may  include  twenty 
steps,  according  to  our  definition.  When  you  try  to  get  this  information 
from  an  informant,  it  will  be  necessary  for  you  to  make  clear  to  him 
what  you  mean  by  "step,"  or  you  may  get  a  very  erroneous  impression. 

Number  of  SB  Steps  and  Number  of  Possible  SB  Steps — SB  means 
Specialized  Behaviors.  SB  steps  are  steps  that  the  trainees  who  will 
be  learning  the  task  cannot  be  expected  to  be  able  to  perform  without 
any  training  on  this  task.  They  are  the  steps  which  will  require 
special  attention  during  training.  Some  SB  steps  may  be  very  quickly 
learned,  such  as  reading  a  meter  with  an  unusual  scale.  Once  the  scale 
is  explained  to  the  trainee,  he  can  read  the  meter.  Other  SB  steps 
may  require  extensive  practice,  such  as  making  fine  discriminations 
about  aspects  of  a  scope  pattern  in  a  maintenance  procedure. 

If  the  procedure  is  branched,  you  will  record  the  number  of 
possible  steps  which  are  SB.  This  figure  refers  to  the  entire  procedure 
and  not  to  any  specific  path  through  the  procedure  (such  as  the  longest 
path).  Your  informant  should  consider  all  of  the  steps  that  could 
possibly  be  performed  within  this  procedure  and  estimate  the  number  of 
these  which  can  be  called  Specialized  Behaviors. 

Describe  SB  Steps — The  information  needed  about  SB  steps  is 
what  makes  them  specialized,  that  is,  why  are  they  not  familiar  to  the 
average  input  trainee.  Do  they  include  tricky  discriminations,  par¬ 
ticularly  rapid  responses,  knowledge  of  unfamiliar  terms  or  other  skills 
and  knowledges  not  likely  to  be  in  the  behavior  repertoire  of  the 
trainee? 
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Do  not  include  any  statements  that  the  trainees  will  have  to 
learn  the  names,  appearance,  and  locations  of  controls,  displays,  or 
other  items  of  equipment.  This  is  always  true,  so  there  is  no  point  in 
saying  it  about  every  task  individually. 

For  some  procedures  it  will  be  most  informative  to  give  an 
overall  picture  of  the  general  character  of  the  specialized  steps.  In 
others  it  will  be  better  to  describe  some  of  the  steps  individually. 

The  description  which  conveys  the  most  accurate  and  complete  picture 
is  always  the  best  description. 

2.  Continuous  Perceptual-Motor  Activity 

-Check  which  kind.  Guiding  a  vehicle  can  be  done  either 
from  inside  the  vehicle  or  remotely,  as  with  certain  kinds  of  missiles. 
A  remote  manipulator  may  be  artificial  hands  for  handling  "hot" 
materials,  a  crane,  or  other  remotely  operated  handling  devices.  Keep¬ 
ing  cursor  on  target  may  mean  aiming  a  rifle  at  a  running  infantryman, 
keeping  crosshairs  on  a  blip  on  a  scope,  or  visual  tracking  with  a 
theodolite.  If  it  seems  best,  simply  write  in  wb*t  the  activity  is, 
rather  than  checking  one  of  the  types. 

Displays  and  Controls — Check  which  are  used. 

Control-Display  Relationship — What  happens  to  the  controlled 
object  (crosshairs,  missile,  etc.)  when  the  controls  are  moved?  The 
control-display  relationship  in  most  tracking  tasks  can  be  character¬ 
ized  under  the  three  headings:  Position,  rate,  or  acceleration  control. 
A  few  tasks,  such  as  controlling  the  pitch  of  a  helicopter  or  the  depth 
of  a  submarine,  may  involve  control-display  relationships  of  a  higher 
order.  Higher  order  relationships  should  be  indicated  beside  the  word 
"other"  on  the  form.  Lag  and  backlash  are  factors  which  introduce  a 
delay  between  the  instant  the  control  is  activated  and  the  instant  the 
display  starts  to  react.  Both  can  make  the  task  more  difficult  and 
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their  presence  should  be  noted.  Backlash  refers  to  free  play  in  the 
control.  Lag  has  to  do  with  the  rate  of  signal  transmission  between 
control  and  display  or  reaction  delays  inherent  in  the  display. 

Error  Tolerance  or  Accuracy  Required — In  some  cases  you  may 
be  able  to  determine  a  quantitative  requirement,  such  as  "must  place 
lifted  object  within  one  inch  of  surveyed  spot."  In  other  cases, 
the  requirements  may  be  much  less  clear-cut,  like  "must  be  on  target 
80%  of  time."  In  this  case,  find  out  what  "on  target"  means.  How  far 
off  the  center  is  still  "on  target?"  Try  to  obtain  a  definition  of 
required  limits  of  accuracy,  as  well  as  the  proportion  of  time  this 
level  oc  accuracy  must  be  achieved. 

3.  Monitoring 

Display — Indicate  the  way  in  which  the  monitor  gets  his  in¬ 
formation—  the  type  of  display  to  which  he  must  pay  attention. 

Relevant  Attribute— Check  the  attribute  or  event  which  will 
cause  a  detection  response.  If  the  operator  is  watching  a  radar  scope, 
you  will  indicate  in  this  item  whether  he  is  instructed  to  respond 
when  a  previously  stationary  blip  starts  to  move,  when  a  new  blip 
first  appears  on  the  screen,  or  when  a  blip  on  the  screen  starts  to 
change  in  size  or  shape. 


Object  or  Signal  to  be  Monitored— Whenever  one  is  monitoring, 
he  is  looking  for  an  object  or  signal  which  has  certain  "relevant 
attributes."  Notice  that  each  item  under  "Relevant  Attribute"  ends 
with  the  words  "object  or  signal."  Whatever  these  words  represent 
in  this  particular  task  is  the  information  entered  in  the  item  "Object 
or  signal  to  be  monitored." 


Suppose  an  operator  is  watching  a  radar  scope  in  order  to 
detect  the  entrance  of  moving  targets  into  radar  range.  You  would  check 
"scope"  under  "display,"  "appearance  of  object  of  signal"  under  "relevant 
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attribute  ,n  and  you  would  write  "moving  target  blip"  under  "object  or 
signal  to  be  monitored."  You  would  not  check  "movement  of  object  or 
signal"  because  the  operator  was  instructed  to  react  when  a  moving 
target  appears  and  not  when  a  target  which  is  present  starts  to  move. 

Estimated  Frequency  of  Events — How  many  of  the  watched-for 
events  will  occur  per  minute ,  per  hour,  per  watch,  per  shift?  How 
often  will  the  detection  response  typically  occur? 


Search  Area — Is  he  watching  a  whole  10"  scope  or  only  one 
quadrant  of  a  scope?  Is  he  to  scan  180  degrees  off  the  starboard  side 
of  a  ship?  The  search  area  may  be  stated  in  square  inches  or  square 
feet  or  in  terms  of  degrees.  If  the  operator  is  monitoring  only 
auditory  signals,  this  item  does  not  apply.  Do  not  enter  such  infor¬ 
mation  as  the  range  of  the  operator's  radar  set  under  this  item. 


Are  Events  Easy  to  Detect? — Answer  "yes"  or  "no." 


How  Should  Detection  Be  Made?— If  you  have  answered  "no"  to 
the  above  question,  state  why  the  detection  is  difficult  and  state,  as 

best  you  can,  how  the  monitor  discriminates  between  an j  event  which  calls 

I 

for  a  detection  response  and  one  which  does  not.  / 

/ 

4.  Communicating  ’ 


Media  and  Special  Knowledge  Requirements — These  items  are  self- 
explanatory. 

5.  Decision  Making  and  Problem  Solving 

There  are  three  general  classes  of  procedures  by  which  decisions 
are  made  and  problems  are  solved; 

a.  When  an  operator  considers  only  one  of  several  avail-  ' 
able  alternative  courses  of  action  because  of  a  rule- 
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of-thumb,  special  knowledge  or  experience,  or  memory 
of  what  action  has  proven  successful  in  the  past,  he 
is  making  a  decision,  so  long  as  he  could  have  chosen 
to  do  something  else  or  to  do  nothing  about  the 
situation.  He  does  not  evaluate  alternative  courses 
of  action  because  he  judges  the  present  situation  to 
be  sufficiently  similar  to  one  in  which  a  certain  course 
of  action  has  proven  to  be  consistently  successful. 

b.  For  certain  decisions  or  problems,  the  operator  has  a 
set  of  standards  or  criteria  in  mind  which  define  an 
acceptable  solution.  He  considers  one  alternative 
action  or  solution  at  a  time  until  he  finds  one  which 
is  "good  enough"  by  his  set  of  criteria.  He  then 
implements  that  alternative. 

c.  A  third  way  of  making  decisions  is  sometimes  possible. 

If  the  decision  maker  knows  most  of  the  possible  alter¬ 
natives,  he  can  select  a  set  of  reasonable  alternatives 
and  evaluate  each  one  against  all  others.  The  one  that 
comes  out  best  in  terms  of  his  criteria  is  the  one  he 
will  adopt  and  implement. 

In  the  first  class  of  decision  making  and  problem  solving, 
the  operator  makes  a  "snap"  decision  without  evaluating  alternatives. 

In  the  second  class,  he  looks  for  a  solution  which  is  satisfactory  \ 
until  he  finds  one.  In  the  third  class,  he  compares  a  full  set  of 
reasonable  alternatives  and  picks  the  best  one.  The  three  classes  of 
decision  making  may  be  illustrated  by  the  following  example.  Consider 
a  troubleshooter  working  on  a  piece  of  electronic  equipment,  who  has 
concluded  on  the  basis  of  the  symptom  pattern  that  the  fault  lies  in 
one  of  the  tubes.  He  must  now  decide  which  tube  to  replace.  If  he 
replaces  one  without  testing  it  because  that  tube  has  caused  the  most 
trouble  in  the  past,  this  is  a  decision  procedure  of  Type  a.  If  he  puts 
one  tube  in  the  tester  at  a  time  until  one  looks  bad  to  him,  this  is  a 
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Type  b  decision  procedure.  He  does  not  test  all  of  the  tubes  unless 
the  bad  tube  happens  to  be  the  last  one  he  chooses  to  test,  his  standards 
of  rejection  are  too  low,  or  the  tester  is  not  working  well.  Using 
Type  £  decision  procedure,  he  would  test  all  the  tubes  and  write  down 
or  remember  the  results  of  each  test.  He  would  then  replace  the  tube 
that  got  the  worst  set  of  readings. 

Indicate  the  type  of  decision  making  or  problem  solving 
which  is  prevalent  in  the  current  task  and  list  the  items  of  kinds  of 
information  which  enter  into  the  making  of  these  decisions  or  the 
solving  of  these  problems. 

F.  Recapitulation  and  a  Look  Forward  - 

Training  Situation  Analysis  is  performed  in  five  stages.  You  have 
read  about  System  Familiarization  and  the  Task  Analysis  Method.  In 
Section  II  you  have  learned  how  to  gain  an  orientation  to  the  training 
problem,  the  system  structure  and  flow,  and  the  equipment  which  is 
involved.  Section  III  described  the  method  for  delineating  the  task 
attributes  relevant  to  making  fundamental  decisions  about  training  and 
training  devices.  When  you  have  described  all  of  the  tasks  in  a  system 
in  terms  of  the  data  called  for  by  TAM,  you  have  completed  the  TAM  phase 
of  TSA.  You  are  then  ready  to  evaluate  the  functional  training  require¬ 
ments  of  the  system.  The  Functional  Training  Requirements  (FTR)  stage 
of  TSA  is  the  stage  in  which  basic  decisions  are  made  about  the  gross 
features  of  the  ultimate  training  program.  These  decisions  are  made 
on  the  basis  of  the  information  gathered  in  TAM.  TAM  represerts  the 
current  best  estimate  of  the  body  of  information  required  to  make  these 
decisions.  It  was  devised  to  obtain  all  of  the  information,  and  to 
omit  none  of  the  information,  required  to  enable  the  TSA  team  to  state 
the  general  attributes  of  an  optimal  training  program  for  any  given 
system. 
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The  process  of  translating  task  descriptions  into  functional 
training  requirements  has  been  analyzed,  in  a  preliminary  fashion, 
during  the  development  of  TAM.  However,  an  explicit,  step-by-step 
procedure  has  not  as  yet  been  devised  for  the  FTR  stage  of  TSA.  A 
person  who  is  fairly  sophisticated  in  both  the  methodology  of  TAM  and 
in  the  planning  of  training  programs  should  be  able  to  use  the  TAM  task 
descriptions  to  derive  functional  training  requirements  for  a  system. 
Until  the  process  whereby  these  decisions  are  made  is  stated  explicity, 
however,  the  training  solution  adopted  for  any  given  system  will  be 
partially  based  upon  the  judgment  of  the  "expert"  making  the  decisions. 
The  writing  of  a  procedure  for  weighting  and  combining  the  TAM  data  in 
order  to  derive  the  functional  training  requirements  is  seen  to  be  the 
next  step  in  the  development  of  TSA. 

The  next  section  of  this  report  (Section  IV)  will  describe  the 
Training  Analysis  Procedure  (TAP).  TAP  is  a  process  whereby  a  training 
priority  is  assigned  to  each  task,  on  the  basis  of  the  cost  and  the 
potential  gain  in  performance  attributable  to  training.  In  developing 
a  solution  tc  the  training  problem,  the  training  situation  analyst  aims 
to  maximize  the  benefit  to  system  performance  resulting  from  training 
and  to  ensure  the  most  efficient  expenditure  of  funds.  TAP  enables 
him  to  consider  the  cost  of  accomplishing  each  proportional  improvement 
in  system  performance .  The  task  associated  with  the  greatest  potential 
improvement  per  training  dollar  is  selected  for  training  first.  Assuming 
that  training  devices  have  been  purchased  for  training  the  first  task, 
the  analyst,  searches  for  the  task  which  offers  the  next  largest  per¬ 
formance  improvement  per  dollar.  The  training  device  system  is  thus 
constructed,  task  by  task,  until  a  budgetary  limit  is  reached.  When  the 
funds  allocated  for  training  devices  are  limited,  TAF  enables  the 
analyst  to  specify  the  training  program  which  would  effect  the  greatest 
gain  in  system  performance  for  the  available  amount  of  money . 


73 


NAVTRADEVCEN  1218-4 


SECTION  IV* 

GUIDELINES  FOR 

TRAINING  ANALYSIS  PROCEDURE  (TAP) 


A.  Introduction  to  TAP 


1.  A  Definition  of  TAP 


Training  Analysis  Procedure  (TAP)  is  a  technique  of  system 
analysis  which  provides  a  ranking  of  tasks  within  a  system  in  terms 
of  the  payoff  of  task  training  (as  reflected  by  improved  system  operation) 
per  training  equipment  dollar  expended. 

The  basic  philosophy  of  the  method  is  that  in  every  system 
there  are  tasks  which,  with  training,  contribute  more  or  less  significantly 
to  the  achievement  of  system  goals.  It  rests  with  the  training  situation 
analyst  to  determine  which  tasks,  any  or  all,  should  be  trained,  and  to 
what  benefit  in  system  performance.  The  method  also  recognizes  that  a 
selection  of  tasks  for  training  may  be  constrained  by  budgetary  limitations, 
and,  therefore,  it  may  be  necessary  to  place  priorities  on  tasks  to  be 
trained . 


The  method  examines  each  task  in  the  system  in  its  relationship 
to  system  goals  and  to  other  tasks  in  the  system.  It  enables  the  analyst 
to  determine,  for  each  task,  and  for  combinations  of  tasks,  the  improve¬ 
ment  in  system  performance  as"  a  result  of  training. 

2.  The  Term  "System"  as  Used  in  TAP 

TAP  is  a  method  of  system  analysis.  A  system  is  traditionally 


*  This  Section  was  originally  written  by  C.  E.  Van  Albert,  G.  G.  Jeantheau, 
J.  T.  Gorby,  and  J.  A.  Parrish  and  published  as  NAVTRADEVCEN  1169-2. 

The  present  authors  have  made  a  few  alterations  in  this  Section,  for 
which  the  original  authors  should  not  be  held  responsible.  The  most 
extensive  changes  are  in  the  treatment  of  Mixed  Systems. 
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defined  as  "...  a  group  of  things,  i.e.,  men  and  equipment,  organized 
to  achieve  a  state  or  purpose."  In  the  application  of  TAP,  it  is  impor¬ 
tant  that  the  system  to  be  analyzed  meet  this  definition.  The  system 
under  consideration  must  have  a  clearly  definable  output.  This  output 
may  be  in  terms  of  targets  killed,  missiles  fired,  information  provided, 
buoys  set,  ships  deployed,  etc.,  but  it  must  be  definable. 

One  essential  feature  of  TAP  is  that  it  considers  task  training 
only  insofar  as  it  influences  system  output.  Thus,  this  output  must 
be  measurable.  In  this  techinque  training  on  individual  tasks  is  only 
important  if  it  improves  system  performance. 

3.  Task  Criticality 

The  theoretical  foundations  of  TAP  require  that  some  attention 
be  given  to  the  notion  of  task  "criticality."  One  assumption  underlying 
TAP  is  that  all  tasks  identified  for  analysis  are  critical  to  system  op¬ 
eration,  in  the  sense  that  task  failure  results  in  system  failure.  How¬ 
ever,  it  is  recognized  that  tasks  may  vary  in  their  relationship  to 
system  success  or  failure.  It  is  further  recognized  that  there  are 
degrees  of  system  performance  degradation  that  may  be  caused  by  poor  per¬ 
formance  of  a  task.  Although  TAP  does  not  accommodate  "degrees  of 
criticality"~a  task  is  either  critical  to  system  operation  or  it  is  not-- 
considerable  latitude  is  permitted  in  applying  the  requirement  that 
only  critical  tasks  be  included  in  the  analysis.  The  rule  of  thumb  to 
be  applied  is  as  follows:  If  any  errors  which  can  abort  system  operation 
can  occur,  however  unlikely  such  errors  may  be  or  however  unlikely  it 
may  be  that  such  errors  would  abort  the  system  operation,  the  task  may 
be  termed  critical  and  should  be  included  in  the  analysis. 

4.  Performance  Estimation 

The  TAP  technique  assesses  the  effects  of  training  on  indivi¬ 
dual  tasks  and  relates  these  effects  to  system  performance.  In  order  to 
make  this  assessment,  performance  on  the  task  before  and  after  training 
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must  be  estimated.  The  estimates  used  in  this  analysis  are  time  to  per¬ 
form  the  task,  the  rate  at  which  the  task  is  performed,  and  accuracy  of 
performance  on  the  task.  Thus,  the  method  requires  the  analyst  to 
obtain  evaluations  of  operator  performance  in  terms  of  both  time  and 
accuracy  for  both  trained  and  untrained  operators. 

The  following  definitions  are  used  in  developing  performance 
data  in  TAP: 

Time  Estimates.— Time  estimates  are  made  in  terms  of  the  time 
required  to  perform  a  task  once. 

Rate  Estimates. — The  estimate  of  the  rate  of  task  performance 
is  the  reciprocal  of  the  time  estimate. 

Accuracy  Estimates. — Estimates  of  accuracy  are  made  in  terms 
of  the  likelihood  that  the  operator  will  perform  the  task  correctly, 
i.e.,  how  many  times  out  of  100  attempts  will  the  task  be  performed 
correctly. 

The  Repetitive  Task. — A  distinction  must  be  made  between  non- 
repetitive  tasks  and  repetitive  tasks .  Nonrepetitive  tasks  are  tasks 
which  are  performed  once,  and  the  system  operates  on  the  output  or  pro¬ 
duct  of  the  performance,  regardless  of  its  quality.  For  example,  when 
a  radar  tracking  operator  reports  a  course,  bearing,  and  speed  for  a 
target,  the  system  proceeds  on  the  basis  of  this  report  even  though  it 
may  be  in  error.  Repetitive  tasks  are  those  which  must  be  repeated 
until  the  performance  is  satisfactory,  in  order  for  the  system  sequence 
to  continue.  This  type  of  task  may  be  illustrated  by  a  fire  control 
radar  operator  who  must  lock  onto  a  target  before  the  system  may  con¬ 
tinue.  If  the  operator  fails  to  lock  on  or  loses  lock  on,  he  must 
repeat  the  necessary  procedures  until  his  performance  is  successful. 
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For  nonrepetitive  tasks  the  accuracy  estimate  is  the  probabi¬ 
lity  that  the  task  will  be  completed  successfully  (according  to  whatever 
criteria  are  applicable  to  the  task  in  question),  the  time  estimate  is 
the  time  to  perform  the  task  once,  and  the  rate  estimate  is  the  recipro¬ 
cal  of  the  time  estimate.  For  a  repetitive  task  the  accuracy  estimate 
is  always  1.0,  since  by  definition  the  task  is  repeated  until  performance 
is  successful.  For  repetitive  tasks  it  is  necessary  to  calculate  expec¬ 
ted  time  or  expected  rate,  which  sire  figures  based  on  both  the  time  to 
perform  the  task  once  and  the  probability  that  a  given  attempt  will  be 
successful,  on  the  average.  Procedures  for  calculating  expected  time 
sind  rate  sire  presented  later. 

The  Monitoring  Task. — Many  systems  include  operator  functions 
which  may  be  called  '•monitoring"  activities.  These  activities  have  been 
identified  in  the  TAM  stage  of  TSA.  In  the  performance  of  such  a  task, 
the  operator  does  not  have  an  "output"  in  the  usual  sense — he  is  monitoring 
for  the  occurrence  of  some  event  or  the  achievement  of  some  condition. 

This  activity  may  be  performed  for  long  periods  of  time — possibly  for 
msmy  system  operational  cycles— before  the  event  or  condition  occurs. 

The  monitoring  task,  then,  does  not  lend  itself  to  the  estimation  of 
time  and  accuracy  obtained  for  output-producing  tasks.  In  TAP,  the 
monitoring  activity  is  not  considered  part  of  the  task,  for  the  purposes 
of  estimating  time  and  accuracy.  However,  this  does  not  mean  that  a 
task  containing  monitoring  behavior  needs  to  be  excluded  from  TAP. 

What  has  to  be  excluded  is  the  part  of  the  task  which  comes  before  the 
event-to-be-detected  occurs.  Time  and  accuracy  estimates  must  be  obtained 
for  the  period  between  the  occurrence  of  the  event-to-be-detected  and 
the  terminal  event  of  the  task.  For  example,  in  a  missile  system,  an 
operator  may  be  monitoring  for  missile  launch  malfunctions.  In  the  per¬ 
formance  of  this  task,  essentially  he  does  nothing  until  a  missile  or 
launch  malfunction  occurs.  However,  when  either  occurs,  he  (l)  detects 
the  presence  of  the  malfunction,  (2)  diagnoses  its  cause,  and  (3)  corrects 
the  condition  or  switches  to  nonmalfunctioning  equipment.  Time  and 
accuracy  estimates  are  assigned  to  these  latter  response  activities, 
rather  than  to  the  monitoring  aspect  of  the  task. 
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Untrained  Performance. — Untrained  performance,  as  the  term  is 
used  here,  refers  to  the  entering  level  of  performance  of  the  operator. 
"Untrained"  means  untrained  with  respect  to  the  subject  system.  What¬ 
ever  the  newly  assigned  or  inexperienced  operator  brings  to  the  task 
in  terms  of  prior  training,  inherent  skill,  or  prior  related  experience 
is  considered  as  part  of  his  response  repertoire.  In  this  connection 
one  must  know  the  characteristics  of  the  newly  assigned  personnel  in 
the  system — the  personnel  who  will  undergo  the  training.  Are  they 
drawn  directly  from  boot  camp  or  are. they  senior  personnel  transferring 
from  a  different  but  related  system?  In  either  case,  the  performance 
capability  of  the  newly  assigned  man  in  the  subject  system  is  the  un¬ 
trained  performance. 

Trained  Performance. — Trained  performance  refers  to  the  level 
of  performance  in  the  subject  system  achieved  as  a  result  of  whatever 
training  is  indicated  for  the  subject  system. 

It  should  be  pointed  out  that  the  validity  of  the  results  ob¬ 
tained  in  TAP  analysis  rests  in  large  measure  on  the  precision  of  the 
performance  estimates  which,  in  turn,  depends  on  the  effectiveness 
with  which  the  previous  stages  of  TSA  have  been  carried  out.  Estimates 
cannot  be  made  properly  without  a  great  deal  of  prior  research  about 
the  system,  the  tasks  involved,  and  the  operator  performance  required 
for  the  tasks.  Estimates  should  be  made  carefully  and  rigorously — not 
by  simple  speculation.  They  should  be  guided  by  the  broad  outlines  of 
the  ultimate  training  program  provided  by  the  Functional  Training  Require¬ 
ments  stage  of  TSA. 

.A  practical  discussion  of  how  these  estimates  are  obtained, 
including  the  possible  pitfalls,  limitations,  and  difficulties,  is 
given  later  in  this  section. 
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B.  The  Selection  of  Tasks  for  the  Training  Environment 
1.  The  Effects  of  Training 

TAP  uses  several  computational  models,  according  to  the  character¬ 
istics  of  the  system  being  analyzed.  This  portion  of  the  guidelines 
provides  an  overview  of  the  models  used  and  identifies  situations  appro¬ 
priate  to  the  application  of  each  of  the  models. 

•  Figure  of  Merit  (FOM) 

Utilizing  the  time  and  accuracy  estimates  for  untrained 
and  trained  perf ormance ,  a  measure  of  effectiveness  is  developed  which 
relates  the  training  provided. for  each  task  to  improvements  in  system 
performance.  This  measure  is  termed  Figure  of  Merit  (FOM).  It  expresses 
the  percentage  improvement  in  system  performance  as  a  result  of  training 
on  individual  tasks. 


! 

] 

i 


For  purposes  of  applying  TAP,  systems  are  classified  as 
Rate  Systems,  Fixed  Sequence  Systems,  or  Mixed  Systems.  The  models 
presented  in  the  following  sections  are  models  for  computing  the  FOM 
for  systems  in  these  different  classifications.  In  these  models  the 
following  notation  is  used  for  the  terms  discussed  thus  far  in  this 
handbook.  This  notation  will  be  used  in  the  following  sections  as 
the  computational  models  are  presented.  Additional  notation  will  be 
presented  as  required. 

Time  estimate  for  untrained  performance  on  the 
ith  task. 

Time  estimate  for  trained  performance  on  the  ith 
task. 

» 
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P^u  =  Probability  of  successful  performance  for  the 
untrained  operator  on  the  ith  task. 

P^  =  Probability  of  successful  performance  for  the 
trained  operator  on  the  ith  task. 

r^u  =  Kate  at  which  the  ith  task  is  performed  by  the 
untrained  operator. 

r^t  =  Rate  at  which  the  ith  task  is  performed  by  the 
trained  operator. 

Note:  Rate  is  computed  by  taking  the  reciprocal  of  the 
sum  of  time  estimates  for  all  tasks,  i.e.,  r.  =  ,  r. .  =  t— -• 

1U  o .  ID  .  , 

1U  it 


a.  Rate  Systems 


The  distinguishing  characteristic  of  rate  systems  is  the 
independence  of  task  performances  from  the  system  cycle,  such  that  all 
tasks  may  be  repeated  at  any  time  after  they  are  completed.  An  example 
of  this  type  is  a  missile  system  in  which  the  initial  event  in  system 
operation  is  the  detection  of  a  target,  and  the  last  event  is  the  firing 
of  a  missile.  In  such  a  system,  the  detection  operator  is  free  to  detect 
another  target  before  the  first  target  is  fired  upon;  in  fact,  immediately 
after  the  detection  of  the  first  target.  Procedurally,  the  method 
examines  only  one  system  cycle,  but  within  that  one  cycle  tasks  may 
cycle  a  number  of  times,  i.e.,  may  be  performed  at  some  "rate."  A 
pure  rate  system  is  one  in  which  all  tasks  in  the  system  are,  in  this 
manner,  independent  of  the  system  cycle. 

Since  tasks  are  performed  at  some  "rate,"  the  system  can 
be  viewed  as  cycling  at  some  rate  rather  than  cycling  in  a  given  amount 
of  time.  System  performance  can  be  expressed  in  terms  of  system  rate. 
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In  rate  systems  the  determinant  of  system  rate  is  the  task  with  the 
slowest  rate.  The  system  cannot  operate  at  a  rate  greater  than  that 
of  its  slowest  task.  Rate  system  performance  may  be  improved  in  both 
accuracy  and  rate  with  training.  The  following  expression  which  in¬ 
corporates  the  rate  feature  represents  the  figure  of  merit  for  rate 
and  accuracy: 


F0MR&A  = 


[  .  lii. 

Piu  riu 


x  100 


(1) 


where:  FOM.^  =  Figure  of  merit  for  rate  and  accuracy. 


it 

P. 

1U 


=  Ratio  of  trained  and  untrained  accuracy  estimates. 


! 


— —  =  Ratio  of  rates  for  trained  and  untrained  performance. 

1U 

The  Bottleneck  Task— As  noted  above,  a  rate  system  cannot 
operate  at  a  rate  greater  than  that  of  its  slowest  task.  If  all  of  the 
tasks  in  a  system  must  be  performed  once  in  order  to  produce  a  system  out¬ 
put,  and  if  all  tasks  may  be  repeated  as  soon  as  they  are  completed,  then 
after  some  number  of  system  cycles  all  the  other  tasks  will  have  been 
completed  at  the  time  the  slowest  t?.sk  is  begun.  At  this  point,  the 
system  rate  equals  the  rate  of  performance  of  the  slowest  task.  The 
slowest  task  creates  a  "bottleneck"  in  system  operation.  Improvements 
in  system  rate  can  only  be  achieved  by  improving  the  rate  of  the  bottle¬ 
neck  task. 


Formula  (1)  given  above  applies  only  to  the  bottleneck 
task.  Training  on  tasks  other  than  the  bottlenecK  task  can  yield  im¬ 
provements  in  system  accuracy  only.  FOM's  computed  for  tasks  other 
than  the  bottleneck  task  are  for  accuracy  improvements  only: 
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POM 


A  only 


x  100 


(2) 


b.  Fixed  Sequence  Systems 

The  definitive  feature  of  the  fixed  sequence  system  is 
the  existence  of  a  sequential  dependency  between  tasks  such  that  no  task 
in  the  system  can  be  started  until  the  previous  task  in  the  sequence 
has  been  completed,  and  the  first  task  in  the  system  cannot  be  repeated 
until  the  last  task  in  the  system  has  been  completed.  Thus*  given  a 
system  with  tasks  1  through  n«  each  task  must  be  done  in  order  and  the 
first  task  must  wait  for  the  completion  of  the  nth  task  before  it  is 
performed  again.  A  buoy-setting  system  is  an  example  of  this  type. 

All  of  the  tasks  must  be  performed  in  the  correct  order  and,  if  the 
first  task  is  ’'steam  to  location"  and  the  last  task  is  "set  buoy," 
clearxy  the  system  will  not  steam  to  a  new  location  until  the  previous 
buoy  is  set. 


Improvements  in  system  performance  in  fixed  sequence  systems 
are  in  terms  of  system  accuracy  and  system  operating  time.  System  oper¬ 
ating  time  is  the  sum  of  individual  task  times  along  the  Critical  System 
Time  Path  (CSTP).  Thus,  the  maximum  time  it  will  take  for  the  system 
to  operate  is  the  amount  of  time  it  takes  all  the  operators  on  the  CSTP 
to  perform  their  tasks  at  their  untrained  level  of  performance.  The 
notation  used  for  this  term  is: 

System  operating  time  =  Et^u 

Critical  System  Time  Path  (CSTP)— In  computing  the  system 
operating  time,  one  must  recognize  that  a  system  may  have  various  "paths," 
or  alternative  channels  of  activity  sequence.  This  concept  may  be 
demonstrated  by  diagramming  the  system  as  a  network  in  which  tasks  are 
represented  by  line  segments  which  link  a  sequence  of  events,  represented 
by  circled  figures.  Consider  a  system  with  the  following  characteristics: 
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1-2  2-3  3-4  4-5  5-6 

0 — <l> — <D — <© — <D — <D 

This  is  a  single-path  system  in  which  the  sequence  of 
tasks  is  1-2 t  2-3,  3-4,  4-5,  5-6.  Untrained  system  operating  time  is 
expressed  as  Zt^,  and  for  this  system  is  simply  the  summation  of  the 
untrained  time  estimates  for  all  tasks,  1-2  through  5-6. 

However,  consider  a  system  of  the  following  type: 

* 

1-2  2-3  5-6 

© — <D — — —^(D — <D 
a  q — <© — — »@ 

b  Q — <© — k© - k© — <D 

In  this  case ,  at  event  3,  two  subsequent  tasks  are  per¬ 
formed  simultaneously'  forming  a  multiple-path  system.  The  two  paths  are: 
A,  which  includes  tasks  1-2,  2-3,  3-4,  4-5,  5-6;  and  B,  which  includes 
tasks  1-2,  2-3,  3-5,  5-6.  Each  path  has  a  system  untrained  operating 
time  (Etiu).  System  operating  time  is  determined  by  the  path  with  the 
greater  2tiu* 


The  system  cannot  operate  in  less  time  than  it  takes  to 
complete  the  longest  path.  This  path  is  called  the  Critical  System  Time 
Path.  Since  the  system  operating  time  is  bounded  by  the  CSTP,  improvement 
in  fixed  sequence  system  performance  time  can  only  be  achieved  by  im¬ 
provement  in  tasks  on  the  CSTP.  The  formulation  used  for  computing 
system  improvement  in  this  case  is:* 

*  Derivations  of  this  formula  and  others  appear  in  NAVTBADEVCEN  1169-1 
Training  Analysis  Procedures,  Volume  I,  Theoretical  Development. 
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where:  FOM^^ 


Figure  of  merit  (percentage  system  improvement 
with  training)  for  time  and  accuracy. 


=  Katio  of  accuracy  estimates  for  trained  and  un¬ 
trained  task  performance  of  the  ith  task. 


£t.-u  =  CSTP  path  time,  system  untrained  operating  time. 

Tasks  Not  on  the  CSTP — In  considering  the  FOM^^,  it 
should  be  recognized  that,  because  of  the  characteristics  of  fixed 
sequence  systems,  this  formulation  applies  only  to  tasks  lying  on  the 
critical  path  (CSTP).  Since,  by  definition,  the  system  cannot  cycle 
in  less  time  than  the  time  of  the  CSTP,  training  on  tasks  which  do  not 
lie  on  the  CSTP  cannot  yield  improvements  in  system  time.  Therefore, 
FOM's  computed  for  tasks  on  paths  other  than  the  CSTP  must  reflect  this 
limitation.  These  FOM's  are  expressed  in  terms  of  potential  system 
improvement  in  accuracy  only: 


Most  systems  do  not  correspond  precisely  to  the  defini¬ 
tions  given  above  for  either  rate  or  fixed  sequence  systems.  The  most 
commonly  found  systems  are  combinations  of  several  groups  of  tasks,  some 
of  which  cycle  as  fixed  sequences  and  some  of  which  cycle  individually 
and  independently  of  other  tasks.  These  systems  are  called  mixed  systems. 


Mixed  systems  are  primarily  rate  systems  in  which  there 
are  blocks  of  tasks  related  as  fixed  sequences.  The  sequences  may 
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include  any  ntunber  of  tasks.  Bach  sequence  cycles  independently  of 
the  remainder  of  the  system.  Such  a  system  is  diagrammed  below. 


A 


Rectangular  symbols  denote  events  which  link  two  tasks 
(or  system  entities)  that  are  related  in  rate  fashion.  A  rate- type  task 
is  shown  with  a  rectangle  at  the  beginning  and  the  end  of  the  task. 
Circular  symbols  represent  events  which  link  tasks  into  a  fixed  sequence. 
If  a  circle  appears  at  either  end  or  at  both  ends  of  a  task  line,  this 
shows  that  the  task  is  part  of  a  fixed  sequence.  Whenever  a  task  cannot 
be  repeated  until  some  later  task  in  the  system  is  completed,  these  two 
tasks  and  all  tasks  between  them  compose  a  fixed  sequence  segment  of  a 
system. 


In  this  diagram,  the  fixed  sequence  of  five  tasks  denoted 

by  A  occurs  in  what  is  basically  a  rate  network.  As  with  pure  rate 

systems,  it  is  necessary  to  determine  the  rate  of  all  of  the  system 

entities  in  mixed  systems,  considering  all  rate- type  tasks  and  the  CSTP's 

of  all  fixed  sequence  segments  as  system  entities.  The  sequence  A  is 

viewed  in  the  same  manner  as  a  task  in  a  rate  system.  It  has  a  rate 

of  performance  (r  ).  If  this  rate  is  slower  than  that  of  any  other 
seq 

system  entity  (rate-type  task,  in  the  present  case),  the  system  rate 
can  be  improved  by  increasing  the  rsg^  for  A.  Since  all  of  the  tasks 
in  the  CSTP  of  a  fixed  sequence  segment  are  sequentially  dependent, 
the  trained  and  untrained  rates  for  that  system  entity  are  given  by: 


seq 


t,  +  t_  +  t, 
lu  2u  3u 


+. . .+  t 


or 


nu 


Et.  sfeq 
xu  ^ 


(4) 
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where : 


r  =  The  sequence  rate  when  sill  tasks  are  untrained, 

seq 


Et.  seq  = 

1U 


The  sum  of  untrained  time  estimates  for  sill  tasks 
in  the  sequence. 


Similarly, 


seq 


Et^seq 


where : 


(5) 


seq 


The  sequence  rate  when  all  tasks  in  the  sequence  are 
trained. 


Etitseq  = 


The  sum  of  trained  time  estimates  for  all  tasks  in 
the  sequence. 


If  it  is  found  that  r  for  sequence  A  is  smaller  than 

Useq 

the  rate  for  any  rate-type  task,  it  may  be  said  that  this  CSTP  is  the 
"critical  entity"  for  the  system.  If  the  rate  of  performance  of  A  is 
improved,  system  rate  can  be  improved  also.  In  determining  the  effects 
on  system  performance  of  training  on  the  tasks  along  the  CSTP,  that  is, 
in  computing  FOM's  for  these  tasks,  the  rate  and  accuracy  formula  is 
applied  because  A  is  the  "critical  entity"  of  the  system. 


F0MH&A 


rit 


r. 

1U 


x  100 


(1) 
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In  applying  this  formula  to  the  CSTP  tasks,  r^  is  given  by: 


rit 


t..  +  t,  +  t_  +....+  t 
it  lu  2u  nu 


(6) 


and: 


iu 


r 

u 

seq 


where : 


r. 

iu 


=  The  sequence  rate  before  training  the  ith  task 
in  the  sequence. 


r 


it 


=  The  sequence  rate  after  training  the  ith  task  in 
the  sequence. 


t  =  The  trained  time  estimate  for  the  ith  task, 

it 


t  ...t  =  The  untrained  time  estimates  for  sill  tasks  in  the 

lu  nu 

sequence  other  than  the  ith  task. 


d.  The  Repetitive  Task 

In  the  formulas  presented  up  to  this  point,  the  terms 
used  for  task  times  are  for  nonrepetitive  tasks.  However,  as  noted 
previously,  the  task  time  for  repetitive  tasks  must  reflect  the  number 
of  attempts  required  to  achieve  successful  performance  or,  in  other 
terms,  the  probability  of  success  on  any  given  attempt.  The  task  time 
for  repetitive  tasks  is  the  expected  time  to  perform,  given  as: 
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iu 


it 


iu 


^iu 


£2E,  pad  for  trained  time,  t*  =  ■  — £S£ 


it  p. 


rep 


it 


rep 


where: 


tfiu’  l'it 


Expected  time  to  perform,  before  and  after 
training. 


tiu  =  Untrained  time  per  given  attempt. 


rep 


tit  =  Trained  time  per  given  attempt. 
1  rep 


Piu  =  Untrained  probability  of  success  per  given 


re^  attempt . 


Pit  =  Trained  probability  of  success  per  given  attempt. 
1  rep 


Thus,  when  computing  FOM'a  for  repetitive  tasks,  the  task  time  used  is 
the  computed  expected  time  for  the  task.  Similarly,  when  computing  both 
Etiu  and  Et^t  for  each  path  in  the  system,  the  expected  times  are  used 
for  repetitive  tasks. 


e.  Time-Bound  Systems 

In  devising  the  theory  which  underlies  TAP,  it  was 
found  convenient  to  define  the  time  period  during  which  the  system  is  to 
be  operated.  This  time  has  been  called  Tau  (T).  This  operating  period 
can  be  governed  by  actions  or  physical  factors  external  to  the  system. 
This  might  be  the  case,  for  example,  in  a  surface-to-air  missile  system 
where  the  operating  time  is  governed  by  the  time  targets  are  within 
range  of  the  system.  On  the  other  hand,  for  certain  systems,  Tau  can 
be  arbitrarily  stated  as  any  time  which  is  long  compared  to  the  time 
required  by  a  single  system  operation.  This  would  be  the  case,  for 
example,  for  am  industrial  production  system.  The  measure  of  improve¬ 
ment  of  such  a  system  would  be  the  increase  in  the  number  of  finished 
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products  produced  in  a  given  time  period  (i.e.,  Tau)  which  could  be 
an  eight-hour  shift,  a  forty-hour  week,  etc. 

Tau  may  be  derived  from  an  operational  specification 
or  calculated  from  a  knowledge  of  the  operational  environment.  For 
example,  if  an  AAW  system  has  a  radar  with  a  100-mile  detection  range, 
and  the  enemy  an  estimated  weapon  release  range  of  40  miles,  the 
system  must  be  able  to  respond  (complete  a  system  cycle)  within  the 
time  it  takes  the  enemy  to  travel  the  60-mile  allowable  engagement 
range.  If  the  estimated  average  enemy  speed  is  600  knots,  this  time 
(Tau)  is  6.0  minutes. 


If  system  operating  time  is  determined  by  factors  external 
to  the  system,  it  must  be  established  initially  that  the  system  can 
complete  at  least  one  operation  during  the  allowed  operating  time.  If, 
before  training,  the  system  cannot  operate  once  during  Tau,  it  is  time 
bound,  and  training  emphasis  must  be  placed  on  those  tasks  which  will 
reduce  system  operating  time. 

To  determine  the  system's  ability  to  respond  within  the 
limits  set  by  Tau,  the  untrained  system  operating  time  (one  system 
cycle)  is  computed. 

When  St.  >  T,  it  must  be  determined  whether  this  is  a 
xu 

training  problem  at  all.  If  Stit  <  T,  then  training  can  reduce  system 
operating  time  to  within  operating  limits.  In  this  case,  training 
should  be  directed  solely  to  reducing  operator  time  until  a  system 
operating  time  less  than  T  is  achieved.  The  model  used  is  given  as: 


fomt 


only 


St. 


1U 


St.  -  t.  +  t.. 
1U  iu  it 


x  100 


(7) 


If  the  system  cannot  operate  within  Tau,  and  the  trained 
system  time  also  exceeds  Tau,  then  it  is  not  a  training  problem.  It 
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is  a  problem  of  system  design,  personnel  selection,  or  some  other  area 
which  is  not  influenced  by  training. 

2.  The  Effects  of  Cost  on  the  Selection  of  Tasks  for  Training 

The  TAP  procedure  provides  for  the  systematic  examination  of 
cost  factors  involved  in  the  development  of  training  device  requirements. 
The  incorporation  of  cost  data  into  this  analysis  is  an  important  and 
necessary  step  to  develop  properly  a  ranking  of  tasks  in  the  order  of 
their  benefit  to  system  performance  per  training  dollar. 

The  basic  inputs  to  this  step  in  the  procedure  are  estimates  of 
equipment  costs  for  training  of  each  task  identified  in  the  system.  It 
is  not  within  the  scope  or  purpose  of  this  section  to  outline  the  pro¬ 
cedures  involved  in  estimating  equipment  costs.  The  purpose  of  the 
following  description  is  to  show  the  nature  of  the  estimates  required 
and  the  way  in  which  they  are  utilized. in  this  method. 

It  should  be  pointed  out  that  the  cost  considerations  discussed 
in  this  section  do  not  purport  to  be  an  all-inclusive  list  of  factors 
involved  in  cost  estimation.  They  are  intended  to  acquaint  the  reader 
unfamiliar  with  this  area  with  the  major  items  of  interest  in  the 
application  of  TAP. 

Since  this  handbook  is  directed  toward  equipment  development, 
the  cost  estimation  discussed  ir»  this  section  is  equipment  oriented. 
However,  TAP  permits  an  identification  of  tasks  which  may  be  trained 
without  incurring  training  device  costs.  Such  tasks  are  included  in 
the  analysis,  and  the  expected  improvement  with  training  on  these  tasks 
is  incorporated  in  the  final  results.  These  tasks  are  referred  to  as 
"zero  cost  items." 

The  required  cost  estimates  should  be  made  by  people  who  are 
expert  in  this  field — not  by  speculation.  The  results  of  TAP  are 
particularly  sensitive  to  the  cost  input,  and  the  estimates  should  be 
made  with  great  care  and  precision. 
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*  Developing  Costs  Per  Task 

For  each  task,  a  cost  estimate  is  made  which  includes 
hardware  costs  and  additional  costs  that  would  be  spent  on  equipment 
for  the  toted  number  to  be  procured.  The  cost  estimate  answers  the 
question,  "If  I  were  going  to  train  on  this  task  and  this  task  only, 
what  would  it  cost?11  For  each  task,  the  equipment  required  to  train 
the  task  is  established,  and  cost  estimates  are  based  on  these  stated 
requirements.  The  establishment  of  the  functional  requirements  of  the 

4 

training  equipment  for  each  task  is  properly  the  concern  of  the  earlier 
stages  of  TSA  (TAM  and  FTR) — it  is  not  a  part  of  TAP.  The  requirements 
developed  in  the  Functional  Training  Requirements  stage  of  TSA  serve 
as  an  input  to  this  step  in  TAP. 

The  equipment  required  to  train  a  task  should  be  grouped 
into  component  hardware  units.  A  component  unit  is  a  distinguishable, 
functional  part  of  a  trainer  which  may  be  procured  a s  a  unit.  For 
example,  a  radar  simulator,  a  synthetic  target  generator,  or  an  analog 
computer  for  an  OFT  can  be  considered  component  units. 

Obviously,  the  determination  of  equipment  required  for 
training  on  each  task  is  a  crucial  step  in  this  analysis.  For  many 
tasks,  there  will  be  alternative  techniques  for  simulation,  cr  different 
concepts  depending  on  level  of  training  desired,  integration  with  other 
part- task  trainers,  etc.  For  example,  one  frequently  encountered 
problem  will  be  the  choice  of  analog  versus  digital  simulation.  For 
individual  task  trainers,  a  likely  choice  will  be  analog  equipment — 
for  large,  complex  system  trainers,  digital  equipment  is  more  appropriate. 
The  TAP  method  conceptually  builds  large  complex  training  systems  by 
collecting  part- task  trainers  in  the  order  of  highest  payoff  per  task. 

This  would  appear  to  present  a  fundamental  obstacle  to  applying  the 
technique.  The  apparent  inconsistency  is  overcome  simply  by  estimating 
costs  for  individual  tasks  and  also  by  obtaining  costs  for  logical 
groups  of  tasks  which,  when  integrated  into  larger  training  device 
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complexes,  would  call  for  a  different  manner  of  simulation.  With  such 
data  in  hand,  the  problem  becomes  a  straightforward  matter  of  substitution 
at  the  proper  point  in  the  iterative  process  of  the  analysis. 

In  this  way,  the  method  actually  permits  a  more  meaningful 

» 

evaluation  of  the  alternatives  involved  in  designing  the  training  system. 

It  should  be  noted,  in  establishing  the  equipment  required 
to  train,  that  performance  estimates  obtained  for  each  task  imply  a  cer¬ 
tain  kind'- of  training.  Different  methods  of  training  with  different 
training  devices  may  yield  significant  differences  in  performance.  The 
particular  training  environment  on  which  the  cost  estimates  are  based 
should  be  the  same  environment  for  which  performance  estimates  were 
derived. 


.  Supplementary  Costs 

In  addition  to  the  hardware  costs  indicated  for  the 
equipment  recommended  for  training,  the  supplementary  costs  for  such 
training  must  also  be  included  in  estimating  the  cost  per  task.  These 
costs  will  include  the  costs  incurred  in  presenting  the  training  course, 
as  well  as  the  costs  involved  in  designing  new  training  equipment  and 
keeping  it  "on  the  air."  A  fullfer  discussion  of  estimating  supplementary 
costs  is  given  on  page  105. 

.  Common  Equipment  Requirements 

The  TAP  procedures  also  take  into  account  commonality 
of  equipment  requirements  between  tasks.  In  many  systems,  a  number 
of  separately  identified  tasks  may  be  trained  with  the  same  equipment 
or  portions  of  the  sa.v  equipment.  On  each  successive  iteration  (see 
pages  130  to  131 ) ,  the  equipment  requirements  of  the  remaining  tasks 
are  examined  against  those  of  the  tasks  selected  for  training  on  pre¬ 
vious  iterations  to  determine  whether  common  equipment  requirements 
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exist.  When  such  commonalities  occur,  the  consequent  cost  reductions 
are  effected— reductions  which  result  from  "buying"  equipment  or  com¬ 
ponent  units  on  previous  iterations. 

3*  The  FOM/COST  Ratio — A  Summary  of  TAP  Procedures 

The  effects  of  task  training  and  the  effects  of  cost  have 
been  formulated  into  a  general  procedure  for  examining  the  entire 
system  at  the  task  level  and  evaluating  system  training  requirements. 

Four  essential  steps  sure  required  in  the  treatment  of  each 

task: 


a.  Estimates  of  performance,  trained  and  untrained,  are  made. 

b.  An  FOM  is  computed. 

c.  Estimates  of  cost  are  made. 

d.  An  FOM/cost  ratio  is  computed. 


As  a  result  of  performing  these  operations  on  each  task  in 
the  system,  it  is  possible  to  single  out  the  task  which  offers  the 
greatest  potential  benefit  to  system  performance  per  training  dollar. 

This  task  is  identified  by  having  the  highest  ^OM/cost  ratio. 

Steps  b,  c,  and  d  are  repeated.  On  each  iteration  the  task 
with  the  highest  FOM/cost  ratio  is  selected  for  training.  Each  time  a 
task  is  selected,  its  trained  time  estimates  are  substituted  for  the 
untrained  time  estimates  on  the  next  iteration.  Thus,  on  each  iteration 
the  representation  of  the  system  reflects  training  on  all  tasks  selected 
on  previous  iterations.  In  this  manner  we  conceptually  "build  a  training 
device  system." 
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Costs  and  percentage  improvement  (FOM)  are  cumulated  after 
each  iteration.  Throughout  the  series  of  iterations,  cost  relation¬ 
ships  ere  utilized.  Frequently,  the  equipment  required  to  train  one 
task  may  also  partially  fulfill  the  requirements  for  another  task. 
The  TAP  procedures  insure  that,  in  such  cases,  cost  reductions  are 
reflected  in  the  tasks  that  have  common  equipment  requirements.  The 
end  product  of  the  iterative  procedure  is  a  ranking  of  tasks  in  the 
system  in  order  of  their  trained  potential  for  system  improvement  at 
minimum  cost. 

C.  Diagramming  the  Network  and  Obtaining  TAP  Data 
1.  The  TAP  Network 


The  purpose  of  the  TAP  network  is  to  depict  the  interrelation¬ 
ships  and  interdependencies  among  the  tasks  in  a  system,  wi,th  specific 
reference  to  the  application  of  TAP.  In  later  steps  in  the  method,  the 
computation  of  FOM's  for  each  task  will  be  based  on  the  nature  of  the 
task  and  its  relationship  to  others.  For  this  purpose,  it  has  been 
found  useful  to  diagram  the  system  operation  in  the  form  of  a  network. 

In  this  format,  certain  points  in  system  operation  can  be 
defined  as  events.  Each  event  is  the  beginning  or  end  point  of  an 

\ 

activity  or  task.  In  charting  the  system  as  a  network,  lines  represent 
activities  or  tasks  and  their  intersections  represent  events  (see  Figure 
9).  The  events  are  numbered  sequentially,  and  tasks  are  referred  to 
by  the  event  numbers  they  link. 


Figure  9»  Multipath  Fixed  Sequence  System 

4 
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_ _ -  Thisdiagram  is  intended  to  show  that  the  system  operates 

in  the  following  manner.  Task  1-2  initiates  system  operation,  and 
when  this  task  is  completed  both  tasks  2-3  and  2-4  cam  commence.  Task 

3- 5  c <m  start  as  soon  as  task  2-3  is  completed.  Similarly,  both  tasks 

4- 5  and  4-6  can  start  when  task  2-4  is  completed.  However,  task  5-7 
cannot  commence  until  both  task  3-5  and  task  4-5  have  been  completed. 

In  other  words,  task  5-7  requires  inputs  from  both  task  3-5  and  task 
4-5.  This  is  also  the  case  for  task  7-8,  which  cannot  start  until  both 
task  5-7  and  task  6-7  have  been  completed.  This  system  is  to  be  con¬ 
sidered  as  a  fixed  sequence  system  if  (and  only  if)  task  1-2  cannot 
start  until  task  7-8  has  been  completed. 

For  convenience  in  distinguishing  between  rate  systems  ar.d 
fixed  sequence  systems,  circles  are  used  to  show  the  events  in  a  fixed 
sequence  system  and  rectangles  represent  events  which  link  two  tasks 
(or  system  entities)  that  are  related  in  rate  fashion.  A  rate-type 
task  is  shown  with  a  rectangle  at  the  beginning  and  the  end  of  the  task, 
Circular  symbols  represent  events  which  link  tasks  into  a  fixed  sequence. 
If  a  circle  is  drawn  at ‘either  end  or  at  both  ends  of  a  task  line,  this 
shows  that  the  task  is  part  of  a  fixed-sequence  segment  of  the  mixed 
system. 


.  Problems  in  Diagramming 

There  are  occasionally  system  configurations  where  it 
is  necessary  to  depict  several  parallel  tasks  which  begin  with  the  same 
event  and  end  with  the  same  event.  This  causes  difficulty  because  the 
TAP  procedure  calls  for  each  task  to  be  identified  by  a  unique  pair  of 
numbers  which  represent  the  initial  and  terminal  events  of  the  task. 

If  several  tasks  have  the  same  initial  and  terminal  events,  they  cannot 
be  differentiated  in  the  usual  way.  The  procedure  for  circumventing  this 
difficulty  is  to  add  a  letter  suffix  to  the  identifying  event  numbers. 

For  example,  if  three  operators  oerform  three  simultaneous  tasks,  and 
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the  events  which  define  the  start  and  end  point  of  each  task  are  the 
same,  this  portion  of  the  system  may  be  drawn  as  follows: 


A 


and  these  three  tasks  will  be  identified  at  1-2A,  1-2B,  and  1-2C , through¬ 
out  the  remainder  of  the  TAP  analysis. 

A  second  problem  in  diagramming  systems  arises  when  one 
encounters  a  task  which  appears  to  have  two  terminal  events.  This 
happens  most  often  when  a  task  is  repetitive  or  is  the  last  task  of  a 
repetitive  sequence  of  tasks  (see  p.  171).  One  of  the  terminal  events 
is  typically  the  initial  event  of  the  next  system  task.  The  others 
cause  the  task  or  repetitive  sequence  to  recycle.  The  only  event  that 

*  “*«v 

should  be  shown  in  the  TAP  network  is  the  event  which  permits  the  system 

cycle  to  continue.  The  events  which  cause  the  task  or  sequence  to 

recycle  must  be  ignored.  However,  the  fact  that  the  sequence  or  task 

is  repetitive  should  be  indicated  by  drawing  a  dotted  line  With  an 

arrow  from  the  terminal  event  of  the  repetitive  task  or  sequence  to 

the  event  which  marks  the  beginning  of  the  repetition,  as  shown  below. 

\  x 

0 — <J> — 0- — <5 — <S> 

.  Realistic  System  Complexity 


As  a  caution  to  the  reader,  it  should  be  pointed  out 
that  the  fictitious  examples  used  in  this  section  have  been  created 
expressly  for  the  exposition  of  the  procedures  used  in  TAP.  For  this 
reason,  the  examples  used  are  purposely  abbreviated  from  what  may  be 
expected  in  some  systems.  The  reader  should  recognize  that  for  some 
large  systems  the  TAP  network  may  be  much  more  complex  than  those  shown 
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for  the  systems  used  here.  The  network  for  a  large  data  processing 
system  is  shown  below  to  illustrate  the  order  of  complexity  that  might 
be  expected  (see  Figure  10). 

.  System  Operating  Modes 


Host  systems  have  several  modes  of  operation.  A  single  sys¬ 
tem  may  have  several  missions.  For  example,  a  shipboard  missile  system 
may  operate  in  both  an  antiair  warfare  (AAW)  mode  and  a  shore  bombard¬ 
ment  mode.  Or,  a  carrier  aircraft  may  fly  an  ECM  mission,  a  bombing 
strike  mission,  an  air  intercept  mission,  or  an  amphibious  support  mission. 
Further,  most  systems  have  a  "normal"  operating  mode  and  a  casualty  or 
back-up  mode.  Treat  these  situations  as  follows: 

(1)  In  charting  systems  for  use  with  TAP,  establish  a 
primary  mission  if  possible,  as  in  the  case  of  an  AAW  weapon  which 
may  also  be  used  for  shore  bombardment.  If  a  primary  mission  cannot 

be  clearly  established,  separate  networks  must  be  prepared  and  separate 
analyses  must  be  conducted  for  each  mission.  The  carrier  aircraft  cited 
above  is  an  example. 

(2)  In  system  networks,  diagram  the  normal  operating  se¬ 
quence  .  If  the  casualty  mode  involves  major  changes  in  operating  proce- 
d-res,  communication  links,  and  personnel,  or  the  use  of  completely  differ- 
c.;.  ..  subsystems ,  prepare  a  separate  network  based  on  the  casualty  which 
introduces  such  changes.  If  the  casualty  mode  involves  simply  switching 

to  redundant  equipments,  to  other  but  identical  consoles,  or  transferring 
the  target  entirely  to  another  weapon  system,  indicate  these  contingency 
actions  at  the  appropriate  points  in  the  normal  sequence  network. 

The  guiding  principle  in  diagramming  systems  for  TAP  is  that 
the  representation  of  the  system  should  include  all  tasks  which  are  to  be 
considered  for  training.  In  many  systems  this  will  mean  creating  a  ficti¬ 
tious  operation  sequence.  For  example,  a  system  may  include  several 
monitoring  tasks  where ,  in  each  case ,  the  operator  is  monitoring 
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Figure  10.  Complex  System  Network 
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for  some  casualty  or  contingency  situation.  Treatment  (2)  above  calls 
for  an  indication  of  the  contingency  actions  at  the  appropriate  points 
in  the  normal  sequence  network.  It  is  highly  unlikely  that  all  major 
contingencies  would  occur  in  a  single  operational  sequence.  However, 
this  is  the  representation  of  the  system  which  should  be  used,  one 
which  contains  all  the  major  contingencies  at  the  appropriate  points. 

2.  Data  Collection 


TAP  is  best  performed  by  an  interdisciplinary  team  of  analysts 
rather  than  by  a  single  individual .  For  example,  a  team  might  be  com¬ 
posed  of:  (1)  a  psychologist  with  background  in  training,  performance 
measurement ,  and  systems,  and  with  experience  in  interviewing;  (2)  an 
engineer  with  experience  in  systems,  training  devices,  and  cost  estimation; 
and  (3)  an  individual  with  some  operational  experience  in  the  system  under 
study,  and,  preferably,  a  familiarity  with  the  training  problems  in  the 
subject  system.  This  variety  of  backgrounds  will  aid  in  developing  a 
more  efficient  approach  to  the  data  collection  process  and  to  the  analysis 
itself. 


TAP  is  simply  a  method  of  organizing  data  about  systems,  about 
tasks,  and  about  training.  It  does  not  create  data;  it  does  not  replace 
good  judgment  and  experience.  The  results  of  the  analysis  are  no  more 
valid  than  the  accuracy  of  the  data  permits.  It  is  incumbent  upon  the 
analyst,  therefore,  to  obtain  the  most  accurate  data  possible. 

The  following  sections  present  some  insights  gained  by  the 
authors  during  the  development  of  the  method  as  to  the  most  effective 
techniques  for  obtaining  the  necessary  information  for  TAP . 

.  Practical  Methods  of  Collecting  Performance  Data 

Sources  of  Estimates— Barring  the  truly  unique  techno¬ 
logical  breakthrough,  most  new  systems  are  improvements  or  advancements 
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over  previous,  existing  systems.  These  new  systems  embody  many  sub¬ 
systems  (and  tasks)  which,  functionally,  are  not  unlike  others  already 
in  existence.  Under  this  assumption,  then,  the  sources  for  the  collection 
of  human  performance  data  in  new  systems  become  clear.  For  each  task  in 
a  new  system  one  must  ask  the  following  questions: 

Is  this  task  or  function  represented  in  some  existing 
system,  either  identically,  or  very  closely? 

If  the  task  is  present  in  another  system,  are  operational 
data  available?  In  the  lead  bureau?  The  system  con¬ 
tractor? 

Can  the  data  be  obtained  through  interviews  with  opera¬ 
ting  personnel?  Is  there  a  training  installation  already 
in  existence  for  this  type  of  task? 

Are  training  data  available?  Can  training  personnel  be 
interviewed?  Does  the  psychological  literature  contain 
research  or  performance  data  on  this  type  of  task? 

If  the  task  cannot  be  related  to  tasks  in  existing  systems, 
it  rests  with  the  training  analyst (s)  to  make  expert  judgments  of  time 
and  accuracy,  with  and  without  practice. 

Interviewing — The  perennial  problem  of  the  task  analyst 
is  that  most  often  he  finds  himself  an  intruder  in  the  working  day  of 
either  operating  personnel,  system  engineers,  or  training  personnel. 

This  is  a  necessary  evil  in  the  collection  of  current,  valid  data. 

TAP  imposes  an  additional  difficulty  in  the  data  collection  process. 

Most  of  the  personnel  noted  above  (operating  personnel, 
engineers,  etc.)  will  be  reluctant  initially  to  provide  performance 
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estimates  in  the  terms  required  by  TAP.  They  do  not  think  of  the  tasks 
they  deal  with  in  terms  of  precise  times-to-perform  and  even  less  in 
terms  of  probability  of  successful  performance.  Therefore,  it  is 
important  to  convey  the  point  that  only  estimates  are  solicited,  not 
hard,  cold  facts. 


i/hen  seeking  performance  estimates  for  TAP,  first  make 
clear  the  distinction  between  trained  and  untrained  operators.  Un- 
trained  performance  is  the  performance  of  an  operator  who  is  procured 
through  the  present  training  and  assignment  channels  and  who  represents 
the  level  of  the  person  likely  to  be  assigned  to  the  task  in  the 
operational  system.  For  example,  the  man  assigned  to  a  submarine  sonar 
system  is  a  Class  A  school  graduate  and  has  been  to  submarine  school. 

This  level  of  prior  background  represents  the  "untrained"  operator  for 
this  system.  Similarly,  senior  decision  makers  in  a  new,  complex  system 
will  probably  be  transferees  who  have  performed  similar  functions  in 
the  system's  less  sophisticated  predecessors.  On  the  other  hand,  some 
tasks  in  the  new  system  may  be  performed  by  trainees  assigned  directly 
from  boot  camp.  Some  judgment  must  be  made  as  to  what  prior  experience 
and  training  nev/ly  assigned  operators  can  be  expected  to  have.  Operating 
personnel  or  training  personnel  are  excellent  sources  of  this  information. 
Define  the  scope  of  the  training  system  under  study  and  solicit  the 
opinions  of  these  personnel  as  to  the  expected  prior  backgrounds  of 
newly  assigned  operators. 

Trained  performance  is  the  performance  of  an  operator 
who  has  received  practice  on  the  training  device  proposed  for  the  task 
by  the  analyst.  When  these  estimates  are  made,  the  analyst  is  saying, 
in  effect,  "If  the  operator  is  given  practice  on  the  device  we  shall 
propose,  his  performance  on  this  task  will  improve  to  this  extent." 

For  the  purpose  of  inquiry,  it  is  best  to  refer  to  the  trained  operator 
in  generic  terms.  "What  performance  would  you  expect  from  a  man  who 
is  fully  trained?"  is  perhaps  the  most  effective  approach.  If  this  is 
interpreted  by  the  informarc  to  include  some  on-the-job  training  in 
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addition  to  the  more  formal  training,  no  ham  is  done  so  long  as  a 
similar  amount  of  on-the-job  training  is  assumed  for  all  of  the  other 
tasks. 


_n  soliciting  this  information,  it  is  particularly  im¬ 
portant  to  establish  the  criteria  of  trained  performance.  The  conditions 
under  which  the  task  must  be  performed  must  be  specified.  In  fact,  the 
range  of  possible  conditions  which  might  occur  in  the  operational  environ¬ 
ment  should  be  determined. 

For  example,  trained  performance  of  a  radar  operator  can 
be  stated  simply  in  terms  of  ability  to  detect  targets  or  track  targets 
on  the  radar  scope.  In  some  situations,  this  definition  would  suffice. 
However,  in  complex  weapon  systems,  the  trained  operator  may  be  expected 
to  read  through  jamming,  track  as  many  as  eight  targets  simultaneously, 
track  through  noise,  sea  return,  and  other  forms  of  signal  degradation. 
These  characteristics  of  the  environment  are  important  to  the  specification 
of  trained  performance  for  the  purpose  of  soliciting  estimates  and  deter¬ 
mining  the  equipment  required  to  train. 

Estimates  of  time  refer  to  the  estimated  average  time-to- 
perform  by  a  typical  operator.  In  most  systems  it  will  be  convenient 
to  express  these  estimates  in  seconds  although  this  is  not  a  requirement. 
However,  time  estimates  for  all  tasks  in  the  system  must  be  in  the  same 
units.  In  many  cases,  a  careful  examination  of  the  task  in  proper  terms 
will  yield  fairly  precise  estimates  of  performance.  For  example,  time 
estimates  for  tasks  involving  the  use  of  radar  scopes  will  be  dependent 
upon  a  standard  antenna  rotation  rate  for  the  radar(s).  Judgements  can 
be  made  in  terms  of  the  number  of  sweeps  required  to  complete  the  task. 

If  it  is  established  that  a  search  radar  has  a  normal  operating  rotation 
rate  of  5  rpm,  it  might  be  judged  that  it  woula  take  an  untrained  operator 
3  sweeps  to  detect  a  target,  or  36  seconds.  A  trained  operator  might 
take  only  2  sweeps  to  detect,  or  24  seconds. 
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In  fact,  in  systems  which  operate  on  radar  data,  the  time 
to  complete  many  of  the  system  tasks  can  be  related  to  the  sweep  rate 
of  the  radar.  Among  these  are  establishing  a  true  track,  identifying 
and/or  evaluating  a  target,  and  obtaining  auxiliary  data  on  a  target 
(raid  size,  height,  etc.). 

For  verbal  reporting  tasks,  simply  looking  at  a  vatch 
while  n«lH ng  a  report  of  representative  content  will  yield  accurate 
estimates  of  time.  For  example,  an  ECM  operator  is  required  to  make  a 
"racket  report"  for  detected  transmissions.  The  content  of  the  report 
is  in  accordance  with  specific  procedure.  A  standard  representative 
time  can  be  established  for  making  this  report  with  a  few  actual  report¬ 
ing  trials. 


If  the  respondent  is  reluctant  to  provide  a  time  estimate, 
the  analyst  should  attempt  to  bracket  the  time  involved  within  a  range 
of  times.  First,  solicit  a  "ball  park  figure."  "Does  it  take  15  minutes?" 
"More?"  "Less?"  "Does  it  take  more  than  5  minutes?"  "Does  7  minutes 
sound  about  right?"  Successive  attempts  should  be  made  to  refine  the 
estimate  once  an  initial  figure  has  been  given. 

It  is  also  of  great  benefit  to  have  the  respondent  review 
the  steps  involved  in  the  task  several  times;  to  go  through  the  task 
mentally  while  he  is  developing  his  estimate.  This  procedure  serves  two 
purposes.  First,  it  insures  that  there  is  agreement  as  to  what  is  in¬ 
volved  in  performing  the  task.  Second,  it  forces  the  respondent  to 
think  carefully  about  the  task  rather  than  to  provide  a  hasty  (and 
possibly  careless)  response  and  to  dismiss  the  subject  too  quickly. 

Estimates  of  accuracy  are  stated  in  terms  of  the  probability 
of  satisfactory  performance  by  the  operator.  In  making  this  judgment, 
the  question  may  be  asked  as  "How  many  times  in  100  performances  will 
the  task  outcome  or  product  be  satisfactory— with  practice— without 
practice?" 
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The  analyst  should  expect  to  encounter  even  greater  reluc¬ 
tance  in  soliciting  this  type  of  information.  The  types  of  errors  which 
can  be  made  and  the  conditions  which  could  precipitate  such  errors  should 
be  explored  with  the  interviewee.  Again,  this  forces  him  to  think  through 
the  task  and  gives  a  greater  likelihood  of  a  valid  response. 


A  Caution — There  may  occasionally  be  system  tasks  which 
the  average  input  trainee  would  not  be  able  to  perform  without  consider¬ 
able  task-specific  training.  When  such  a  task  is  encountered,  the  respon¬ 
dent  would  be  justified  in  saying  that  the  untrained  time  for  the  task  is 
infinite  and  the  untrained  probability  of  correct  performance  is  zero. 
However,  the  analyst  should  not  allow  the  informant  to  use  this  as  a 
device  for  evading  a  difficult  judgment.  If  the  average  input  trainee 
could  perform  this  task  after  a  brief  orientation  as  to  his  duties,  the 
format  used  in  communications,  the  names  and  functions  of  various  pieces 
of  equipment,  or  some  general  information  of  this  sort,  then  a  realistic 
estimate  of  the  performance  level  of  the  typical  trainee  who  has  had 
this  sort  of  orientation  should  be  obtained.  Most  tasks  require  a  short 
briefing  before  they  can  be  performed  by  an  untrained  person.  Such  a 
briefing  should  be  assumed  in  obtaining  untrained  performance  estimates. 

.  Practical  Methods  of  Collecting  Cost  Data 

For  each  task  a  cost  estimate  is  made  which  includes  hard¬ 
ware  costs  and  additional  costs  that  would  be  spent  on  equipment  for  the 
total  number  to  be  procured.  The  cost  estimate  answers  the  question, 

"If  I  were  going  to  train  on  this  task  and  this  task  only,  what  would 
it  cost?"  The  equipment  required  to  train  the  task  must  be  established 
for  each  task,  and  cost  estimates  are  based  on  these  stated  requirements. 

The  results  of  TAP  are  very  sensitive  to  the  cost  data 
used  in  the  analysis.  Since  this  accuracy  requirement  does  exist,  cost 
estimation  should  be  done  by  people  with  experience  in  this  work. 
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Estimates  should  not  be  made  by  speculation.  The  equipment  required  to 
train  a  task  should  be  grouped  into  component  hardware  units.  A  component 
unit  is  a  distinguishable,  functional  part  of  a  trainer  which  may  be 
procured  as  a  unit.  For  example,  a  radar  simulator,  a  synthetic  target 
generator,  or  an  analog  computer  for  an  OFT  can  be  considered  component 
units.  The  list  should  include  alternative  techniques  where  indicated. 

If  the  analyst  is  familiar  with  a  designated  piece  of  existing  equipment 
which  meets  the  requirement,  the  equipment  should  be  so  specified.  Hard¬ 
ware  costs  for  each  task  are  organized  in  tabular  form,  itemized  according 
to  component  hardware  units  and  costs  associated  with  these  units.  The 
form  of  this  table  is  shown  on  page  124. 


•->  vs?  * 


1 


If  an  existing  unit  would  meet  the  requirements  with 
modifications,  this  fact  should  be  specified.  If  the  training  require¬ 
ment  cannot  be  met  with  existing  equipment,  the  functional  characteristics 
of  the  required  unit  must  be  specified  to  the  extent  necessary  to  make 
an  accurate  cost  estimate. 

In  the  TAP  analysis,  a  single  cost  figure  is  used  for 
each  task.  The  cost  figure  represents  the  total  cost  of  all  the  units 
required  for  training  on  that  task.  In  addition  to  the  cost  of  fabricating 
the  equipment  recommended  for  training,  there  are  two  classes  of  sup¬ 
plementary  costs  which  should  be  factored  into  the  estimate  of  cost  per 
task.  One  has  to  do  with  the  supplementary  costs  associated  with  de¬ 
veloping,  operating,  and  maintaining  the  training  devices.  The  other 
relates  to  the  supplementary  costs  incurred  in  presenting  the  training 
course.  The  supplementary  training  device  costs  will  include  such  items 
as  R&D  costs  for  items  which  do  not  presently  exist,  field  service,  spare 
parts,  and  documentation  costs.  The  supplementary  training  course  costs 
will  include  the  cost  of  training  time,  instructors,  classroom  space, 
text  materials,  etc. 


A  strong  effort  should  be  made  to  obtain  direct  estimates 
of  as  many  as  possible  of  these  supplementary  costs  for  each  task.  How¬ 
ever,  the  overriding  consideration  is  that  the  cost  estimates  for  providing 
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training  should  be  based  on  the  same  set  of  factors  for  every  task. 

If  this  requirement  is  not  met,  the  comparison  of  FOM/coat  ratios 
across  tasks,  a  f undam  ntal  step  in  TAP,  becomes  somewhat  meaningless. 

If  estimates  on  all  relevant  cost  factors  for  all  tasks  eure  not  avail¬ 
able,  this  does  not  mean  that  some  factors  should  be  entirely  omitted 
from  consideration.  The  effect  of  basing  a  task's  training  cost  figure 
upon  an  incomplete  set  of  cost  variables  will  be  an  underestimation  of 
any  budgetary  limitations  which  may  exist.  Some  allowance  must  be  made 
for  the  costs  which  will  be  incurred  but  which  cannot  be  estimated  for 
each  task  in  advance. 

If  supplementary  costs  are  computed  by  multiplying  the 
hardware  cost  for  each  task  by  some  constant  percentage,  an  accurate 
figure  for  the  total  cost  of  the  training  program  may  bs  obtained  (to 
the  extent  that  the  percentage  correctly  represents  the  average  re¬ 
lationship  between  equipment  costs  and  supplementary  costs).  However, 
this  procedure  is  not  recommended.  When  supplementary  costs  are  com¬ 
puted  in  such  a  manner,  they  contribute  nothing  to  the  final  ranking 
of  tasks  in  terms  of  system  improve .nent  per  cost  of  training. 

The  recommended  procedure  for  computing  total  task 
training  cost  is  as  follows: 

1.  List  all  cost  variables  which  will  contribute  to  the 
overall  cost  of  the  training  program. 

2.  Select  the  cost  factors  on  which  estimates  can  be  made 
for  each  task  (both  hardware  and  supplementary  costs). 

3.  Obtain  the  above  set  of  cost  estimates  for  every  task. 

4.  Estimate  the  average  percentage  of  the  cost  of  training 
which  is  contributed  by  variables  for  which  cost  estimates 

cannot  be  obtained  on  every  task. 
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5.  Subtract  this  percentage  from  100#  and  divide  it  by  the 
result  of  the  subtraction. 

6.  For  each  task,  multiply  the  resulting  decimal  fraction  by 
the  total  of  the  costs  which  can  be  estimated. 

7.  For  each  task,  add  this  product  to  the  total  of  the  estimated 
costs  to  obtain  the  total  task  training  cost. 

Number  of  Units  for  Procurement — Although  the  present 
procedures  for  TAP  are  based  on  the  assumption  that  the  device  to  be 
developed  is  a  single ,  complex  trainer,  many  such  training  devices  ai"e 
composites  of  a  number  of  part-task  trainers.  These  collective  units 
are  often  composed  of  many  identical  modules  such  as  radar  simulators 
or  target  position  generators .  In  some  cases ,  the  number  of  identical 
modules  is  great  enough  to  effect  a  savings  in  cost  by  buying  in  quantity. 

In  systems  where  a  number  of  different  tasks  require  the  same  module ,  but 
in  different  numbers,  a  schedule  of  costs  per  unit  as  a  function  of 
quantity  should  be  obtained  (see  page  122). 

Common  Cost  Items — The  TAP  technique  conceptually  "builds" 
a  training  device,  task  by  task.  However,  as  each  task  is  added  to  the 
training  curriculum,  the  total  cost  of  training  is  rarely  increased  by 
the  full  cost  of  training  which  has  been  estimated  for  the  added  task. 

With  the  incorporation  of  every  new  task  (after  the  first  one) ,  the  analyst 
must  reevaluate  the  cost  of  adding  the  new  task  to  the  curriculum,  in 
view  of  the  cost  items  which  the  new  task  has  in  common  with  tasks  already 
chosen.  He  must  ask:  "What  will  be  the  Cu.  t  of  adding  training  on  this 
taJ.c  to  the  training  program  which  was  determined  by  the  previous  interations?" 
This  reexamination  will  involve  the  common  supplementary  cost  requirements, 
as  well  as  the  common  hardware  requirements. 

Most  large  training  devices  have  an  instructor 's  console 
associated  with  the  actual  simulation  equipment.  Many  have  a  single 
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computer  which  generates  the  training  environment.  These  units  are 
common  to  all  tasks  in  the  system.  However ,  the  features  of  the  instruc¬ 
tor's  console  or  the  size  or  configuration  of  the  computer  may  vary  as  a 
function  of  the  number  and  kind  of  tasks  incorporated  in  these  units  at 
each  stage  of  the  analysis.  The  specific  requirements  of  each  task  with 
regard  to  such  units  must  be  determined  and  the  consequent  costs  must 
be  developed. 

/ 

Soliciting  Cost  Estimates — In  gathering  cost  data,  it  is 
particularly  important  to  continually  stress  to  the  engineer  that  each 
task  is  being  costed  separately.  He  must  be  cautioned  not  to  think  in 
terms  of  "whole"  devices  but  rather  in  terms  of  functional  units.  When 
several  tasks  may  be  incorporated  into  a  single  subsystem  trainer,  and 
such  a  unit  is  being  costed  as  an  alternative,  the  costs  of  "integrating" 
several  units  must  also  be  included. 

D.  Rate  Systems  -  Procedures 

Rate  systems  are  defined  as  systems  in  which  any  task  in  the  system 
cycle  may  be  repeated  before  the  system  has  completed  its  cycle.  Thus, 
during  any  one  system  cycle,  the  first  task,  or  other  tasks  in  the  system, 
may  be  performed  a  number  of  times,  i.e.,  at  some  "rate."  In  a  "pure" 
rate  system  all  tasks  may  cycle  independently  of  the  system  cycle. 

System  rate  is  then  determined  by  the  task  in  the  system  with  the  lowest 
rate;  the  system  cannot  cycle  at  a  greater  rate  than  its  slowest  task. 
Improvement  in  system  performance  in  rate  systems  is  measured  in  terms 
of  improvements  in  task  rates  as  well  as  accuracy.  This  portion  of  the 
guidelines  presents  the  procedures  to  be  used  in  applying  TAP  to  rate 
systems. 

The  procedures  used  in  TAP  fall  into  five  distinct  steps: 

1.  Preliminary  Analysis  of  the  System  -  The  Network 

This  step  involves  an  analysis  of  the  system  to  identify  the 
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tasks  and  task  sequences  to  be  considered  for  training.  As  part  of 
this  analysis  the  decision  is  made  as  to  whether  multiple  missions 
exist  and  whether  separate  analyses  will  be  required  for  the  missions. 
The  system  is  diagrammed  as  a  network,  and  it  is  determined  whether 
the  rate,  fixed  sequence,  or  mixed  system  models  apply. 

2.  Development  of  the  Task  Table 

Within  this  step,  performance  estimates  are  made  for  both 
trained  and  untrained  operators.  The  performance  estimates  are 
organized  in  tabular  form  and  rates  are  computed. 

3.  Development  of  the  Cost  Table 


For  the  cost  table  the  equipment  required  to  train  each  task  is 
determined.  The  total  costs  of  equipment  per  task  are  obtained  and 
organized  in  tabular  form. 

4.  Iterative  Analysis 


It  is  in  this  step  that  the  data  collected  on  performance  and 
cost  for  each  task  are  analyzed  with  relation  to  the  system  and  to  each 
other.  An  iteration  table  is  developed  in  which  a  FOM  and  the  FOM/cost 
ratios  are  computed  for  each  task.  These  computations  are  carried  out 
in  an  iterative  manner.  As  a  result  of  each  successive  iteration,  a 
task  or  group  of  tasks  is  selected  for  training.  After  each  iteration, 
the  "trained"  data  for  the  task(s)  selected  are  substituted  for  the 
"untrained"  data,  and  the  remainder  of  the  system  is  analyzed  with  the 
previously  selected  tasks  considered  as  "trained." 

Common  equipment  requirements  between  tasks  are  noted  as 
tasks  are  selected,  and  appropriate  adjustments  are  made  to  cost  data 
for  succeeding  iterations.  The  iterative  procedure  is  continued  until 
all  tasks  have  been  selected  for  training. 
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5.  Results 


The  series  of  iterations  described  above  yields  a  ranking  of 
tasks  in  order  of  their  benefit  to  system  performance  per  dollar  of 
equipment  cost.  These  data  sire  most  usefully  presented  in  a  plot  of 
estimated  system  improvement  (FOM)  as  a  function  of  cost.  The  data 
are  plotted  as  a  step  function  where  each  step  represents  the  task(s) 
selected  on  successive  iterations. 

*  *  * 

This  section  discusses  in  step-by-step  detail  the  actual 
procedures  used  in  implementing  TAP  for  rate  systems.  The  procedures 
are  presented  by  means  of  a  hypothetical  system  example — "The  Corridor 
Penetration  System."  The  reader  should  refer  to  Table  4  at  the  end  of 
the  section  as  each  step  is  discussed. 

Five  major  subsections  are  included  in  this  discussion,  each 
representing  a  major  step  in  the  analysis.  These  include: 

a.  The  Network — diagramming  the  system 

b.  The  Task  Table — making  performance  estimates 

c.  The  Cost  Table — making  cost  estimates 

d.  The  Iteration  Table — computing  FOM's  and  ratios 

e.  The  Taole  of  Results — presenting  the  results 

1.  Networks 

In  performing  the  analysis  on  rate  systems,  a  network  diagram¬ 
ming  technique  as  used  similar  to  that  described  under  subheading  C  of 
this  section,  except  that  square  symbols  are  used  for  events  rather  than 
circles.  This  convention  is  adopted  largely  for  later  use  in  mixed 
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systems  when  both  rate-type  and  fixed  sequence  tasks  are  present  in 
a  system. 


To  illustrate  the  procedures  used  for  rate  systems,  the  analysis 
of  a  hypothetical  system  is  followed  step  by  step.  Consider  a  subsystem 
which  might  be  called  the  Corridor  Penetration  System,  with  the  following 
characteristics  as  given  in  this  fictitious  system  description.  (In  this 
illustration,  this  extremely  simple  subsystem  will  be  treated  as  a  complete 
system.) 


"...Based  upon  precise  position  information  received 
from  HQ  Search  Section,  targets  are  located  by  Detec¬ 
tion  Operators  (DO)  it 1  through  #4  on  repeaters  of  the 
AN/ALQ-85  radar.  Upon  detection,  the  DO  interrogates 
the  target  with  the  INT-7  system  and  determines  whether 
the  target  is  hostile.  The  INT-7  system  allows  the  opera¬ 
tor  to  interrogate  two  targets  simultaneously.  Hostile 

> 

targets  are  transferred  to  one  of  two  Classification  Opera¬ 
tors  located  at  the  Mk  1  Classification  Console.  Hostile 
targets  are  also  entered  at  the  Corridor  Penetration  Status 
Board.  Target  classification  is  accomplished  by  inserting 
the  appropriate  classification  code  into  the  computer 
access  channel  and  pushing  the  CLASSIFY  button  at  the 
Mk  1  Console.  Target  classification  is  displayed  to  the 
operator  on  the  classification  panel  of  the  console.  The 
Mk  1  operator  then  transmits,  via  sound-powered  telephone, 
to  the  Air  Threat  Coordinator. 

"On  the  basis  of  the  information  received  regarding  target 
characteristics,  the  Air  Threat  Coordinator  evaluates  the 
threat  of  the  penetration  and  determines  the  availability 
of  defense  forces  at  the  Force  Deployment  Console  (FDC) . 
Available  forces  are  then  assigned  by  the  ATC.  .  .  " 
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The  system  described  may  be  diagrammed  as  shown  in  figure  11.  In  this 
figure  an  event,  as  denoted  by  the  numbers  enclosed  in  each  square,  is 
defined  as  the  beginning  and/or  end  of  a  specific  task  or  activity  in 
the  system  operation.  The  lines  joining  events  represent  tasks.  The 
tasks  are  referred  to  by  the  two  event  numbers  they  link,  as  1-2,  2-3 
etc. 


Location  Interrogation  Post  on  CP  Evaluate  Assignment 

Status  Board 


Figure  11.  Corridor  Penetration  System  Network 

Note  that  at  event  3,  the  completion  of  the  interrogation  task,  two 
activities  begin  and  take  place  simultaneously:  3-4,  the  classification 
task;  and  3-5,  the  posting  of  targets  on  the  CP  Status  Board. 

The  tasks  identified  are  then  collected  in  a  list,  as  below: 


Task  No. 

Task  Description  (Operator) 

1-2 

Target  location  (DO) 

2-3 

Target  interrogation  (DO) 

3-4 

Targot  classification  (CO) 

3-5 

Post  on  CP  Status  Board  (SB  op) 

4-3 

Report  classification  (CO) 
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5-6 

Evaluate  threat  and  force  availability 

(ATC) 

6-7 

Force  assignment  (ATC) 

This  listing  of  tasks  is  then  amplified  into  the  Task  Table  by  the  addition 
of  performance  estimates  for  each  task. 

2.  Task  Table  _  _  _  -  -  - 

For  each  task  shown  in  the  list  above,  estimates  are  made  for 
probability  of  accurate  performance  by  untrained  operators  (p^) ,  proba¬ 
bility  of  accurate  performance  by  trained  operators  (p^.) ,  time-to-perform 
for  untrained  operators  (t^),  and  time-to-perform  for  trained  operators 
(t.).  The  task  table  takes  the  form  shown  in  Table  2,  page  118. 

Computation  of  Rate — For  the  rate  system,  an  additional  step  is 
required  in  the  preparation  of  the  task  table.  The  rate  at  which  each 
task  may  be  accomplished  by  both  trained  and  untrained  operators  must  be 
computed. 


Hate  is  defined  simply  as:' 


riu  t. 

1U 


where:  r.  =  rate  of  the  untrained  task 

1U 


t.  =  time  estimate  for  the  untrained  task  performance 

1U 


*  In  systems  where  the  task  in  question  is  performed  in  parallel,  i.e., 

n. 

l 


an  identical  function  performed  by  more  than  one  operator,  r.  =  -r~ 


iu 


and  r.j.  =  -r —  ,  where  n  =  the  number  of  operators  performing  the  task, 
it  t . , 
it 
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Similarly, 


where:  r^t  =  rate  of  the  trained  task 

t. t  =  time  estimate  for  the  trained  task  performance 

For  this  hypothetical  system,  suppose  the  following  sources  of  information 
are  available: 

a.  A  preliminary  system  operation  manual. 

b.  System  design  engineers. 

c.  A  training  installation  which  trains  on  tasks 
1-2,  2-3,  and  3-4. 

Utilizing  these  sources  the  following  information  is  derived: 

.  Task  1-2  Target  Location 

Accuracy  Estimates — Through  interviews  with  system  design 
personnel  it  is  determined  that  the  nature  of  the  target  location  task 
is  such  that  the  operator  will  never  fail  to  locate  the  target,  given  the 
coordinate  information  from  the  HQ  Search  Section.  Therefore,  for  both 
the  trained  and  untrained  operators  we  assign  a  probability  of  1.0. 

These  figures  are  entered  in  the  task  table  under  p  and  p. . 

Time  Estimates — The  benefit  to  be  derived  from  training 
in  this  task,  however,  is  a  reduction  in  the  time  to  pinpoint  a  target  on 
the  CRT  display.  The  time  for  location  is  cut  in  half  with  training. 
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Interviews  with  training  personnel  at  the  1-2  Training  Installation 

indicate  that  the  normal  sweep  rate  for  the  AN/ALQ-85  Radar  is  10  rpm. 

Each  sweep,  then,  takes  6  seconds.  Untrained  operators  take  an  average 

of  8  sweeps  to  locate  the  reported  target  on  the  PPI.  The  total  time 

is  48  seconds.  Trained  operators  accomplish  this  task  in  4  sweeps  or 

24  seconds.  These  entries  are  made  in  the  task  table  for  t  and  t. , 

u  t 

respectively . 


Rates — There  are  four  Detection  Operators  in  this  system. 
The  rate  for  a  single  untrained  operator  in  locating  targets  at  48 
seconds  per  location  is  1.25  targets  per  minute.  Thus,  four  operators 
locate  4  x  1.25  targets  or  5  targets  per  minute.  This  is  the  maximum 
rate  in  this  particular  function.  Similarly,  the  trained  time  of  24 
seconds  yields  an  individual  operator  rate  of  2.5  targets  per  minute. 
Four  operators  can  process  4  x  2.5  targets  or  10  targets  per  minute. 

These  figures  are  entered  into  the  table  under  r^  and  r^.. 

.  Task  2-3  Target  Interrogation 

System  documentation  provides  the  information  that 
target  interrogation  is  performed  using  a  photoelectric  device  which 
is  part  of  the  INT-7  system.  Personnel  at  the  1-2  Training  Installation, 
who  also  train  on  task  2-3,  estimate  that  untrained  operators  will 
perform  this  function  correctly  90  times  out  of  100  or  with  a  .90 
probability  of  success.  Trained  operators  improve  to  the  point  of 
making  only  one  error  in  100  operations .  The  trained  probability  of 
success  is  .99.  These  figures  are  entered  into  the  table. 

Time  estimates  given  for  the  interrogation  function  are 
2  sweeps  for  untrained  operators  (12  seconds)  and  1  sweep  for  trained 
operators  (6  seconds).  These  figures  are  entered  in  the  taole. 

It  is  learned  from  the  system  documentation  that  the 
INT-7  system  allows  each  operator  to  interrogate  two  targets  simult¬ 
aneously.  The  number  of  targets  capable  of  being  interrogated  at  one 
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time  by  four  operators  is  8.  The  rate  for  individual  untrained  operators, 
at  12  seconds  for  interrogation,  is  5  targets  per  minute.  Since  8  targets 
can  be  interrogated  simultaneously ,  the  maximum  output  in  this  function  is 
40  targets  per  minute.  Similarly,  the  rate  for  trained  operators  is  10 
targets  per  minute  and  80  targets  per  minute  is  the  maximum  output  in  this 
function. 


Task  3-4  Target  Classification 


Target  classification  involves  the  selection  of  an  appro¬ 
priate  numerical  code  according  to  target  type,  size,  and  vector.  Via 
keyset  this  information  is  entered  into  the  computer.  Training  personnel 
indicate  that  learning  the  necessary  codes  and  operating  the  keyset  are 
factors  which  improve  greatly  with  training.  The  obtained  data  indicates 
probabilities  of  .75  for  untrained  operators  and  .98  for  trained  operators. 
Times  given  are  15  seconds  for  untrained  operators  and  10  seconds  for 
trained  operators.  Translated  into  rate,  these  figures  become  ru  =  4 
targets/minute  and  r^  =  6  targets/minute  for  individual  operators. 

System  output  in  this  task  (since  there  are  two  operators)  is  r^  =  8 

targets/minute  and  r  =  12  targets/minute. 

1/ 

.  Task  3-5  Post  on  CP  Status  Board 


This  task  requires  the  CP  status  board  operator  to  enter 
on  the  board  the  classification  of  targets,  received  verbally  from  the 
classification  operator.  Time-to-perform  is  not  a  major  consideration  in 
the  task;  it  does  not  improve  with  training.  System  design  personnel 
indicate  that  the  average  operator  performs  the  task  in  3  seconds. 

However,  personnel  who  have  dealt  with  similar  plotting 
board  tasks  in  other  systems  indicate  that  accuracy  of  performance  in¬ 
creases  somewhat  with  training.  The  estimates  they  give  are  a  decrease 
in  errors  from  5  in  100  to  1  in  100  after  training.  Accuracy  estimates 
of  .95  and  .99  are  entered  accordingly  in  the  task  table. 
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Since  only  one  operator  performs  the  function  (in  3  sec¬ 
onds),  the  rate  for  both  trained  and  untrained  performance  is  20  targets 
per  minute. 


Task  4-3  Report  Classification 


This  task  is  a  simple  reporting  task — a  verbal  communi¬ 
cation  by  tha  Mk  1  operator  to  the  Air  Threat  Coordinator.  The  classifi¬ 
cation  message  is  given  according  to  SOP.  Sample  reporting  trials  are 
timed,  and  the  time  to  perform  is  5  seconds.  The  time  to  report  does 
not  change  with  training.  The  likelihood  of  error  is  zero,  and  probability 
of  successful  performance  is  1.0  for  both  trained  and  untrained  operators. 
These  data  are  entered  in  the  table. 

At  5  seconds  per  report,  2  operators  can  make  24  reports 

per  minute.  These  rates  are  entered  for  both  r  and  r. . 

^  u  t 

.  Task  3-6  Threat  evaluation 

The  Air  Threat  Coordinator  position  is  filled  by  the 
senior  officer.  These  individuals  have  many  years'  experience  in  threat 
evaluation.  Even  though  the  task  requires  a  major  decision,  officers 
of  this  type  estimate  that,  by  transferring  prior  experience  to  the  new 
system,  they  will  make  the  correct  assessment  90  times  out  of  100.  With 
experience  in  the  new  system,  it  is  estimated  that  only  2  incorrect 
decisions  in  100  will  be  made,  giving  a  probability  of  success  of  .98. 

The  time  taken  by  the  -untrained  man  in  weighting  the  target 
information  against  force  availability  is  estimated  at  10  seconds.  With 
experience  on  the  new  system,  it  is  estimated  that  this  can  be  cut  in 
half — to  5  seconds. 

The  10  seconds  untrained  and  5  seconds  trained,  converted 
to  rate,  give  r^  =  6  decisions  per  minute  and  r^.  =  12  decisions  per  minute, 
respectively. 
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•  Task  6-7  Force  Assignment 

Once  the  decision  has  been  made  to  assign  forces,  the  im¬ 
plementation  of  the  decision  is  simply  a  matter  of  transmitting  am  order. 
The  task  is  performed  without  error  by  both  untrained  and  tradned  men  and 
is  accomplished  in  3  seconds,  trained  amd  untrained.  Translated  into 
rate,  this  becomes  20  orders  per  minute,  tradned  and  untrained. 

Table  2.  Corridor  Penetration  System  -  Task  Table 


Task 

pu  pt 

tu 

s 

n 

r 

u 

rt 

1-2  Target  Location  (DO) 

1.0  1.0 

48 

24 

4 

5 

10 

2-3  Target  Interrogat.ion  (DO) 

.90  .99 

12 

6 

8 

40 

80 

3-4  Target  Classification  (CO) 

.75  .98 

15 

10 

2 

8 

12 

3-5  Post  on  CP  Status  Board 

•95  .99 

3 

3 

1 

20 

20 

4-5  Report  Classification  (CO) 

1.0  1.0 

5 

5 

2 

24 

24 

5-6  Evaluate  Threat  and  Force 
Availability  (ATC) 

.90  ?98 

10 

5 

1 

6 

12 

6-7  Force  Assignment  (ATC) 

1.0  1.0 

3 

3 

1 

20 

20 

The  task  table  for  rate  systems  is  set  up  as  shown  above — 
with  three  additional  columns,  for  n,  r  ,  and  r,  .  The  task  with  the 

w 

lowest  rate  determines  the  system  rate.  This  task  can  be  termed  "the 
bottleneck  task."  In  this  example,  the  bottleneck  task  is  ta„.  .-2  with 
a  rate  of  5  target  locations  per  minute.  The  r  and  r.  values  in  this 
table  were  computed  using  the  formulas  shown  above. 

3.  Cost  Table 


A  full  demonstration  of  the  procedures  used  for  developing 
costs  in  TAP  is  given  in  the  following  sections.  Section  a.  is  devoted 
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to  a  discussion  of  the  equipment  required  to  train  each  task.  Section 
b.  is  a  detailed  statement  of  the  cost  estimates  and  the  manner  in  which 
they  are  organized. 

a.  Corridor  Penetration  System  -  Equipment  Required 


Task  1-2  Target  Location 


Task  1-2  is  one  which  involves  the  use  of  a  CRT  display 
of  the  AN/ALQ-85  radar.  A  proper  training  environment  should  include  a 
minimum  of  4  simulated  targets  in  order  to  permit  successive  locations 
by  the  4  detection  operators.  To  train  on  this  task,  then,  an  ALQ-85 
radar  simulator  and  4  radar  target  generators  are  required.  Engineers 
ascertains  1  that  a  "Type  II"  power  supply  would  be  required  for  a 
trainer  incorporating  these  units. 

.  Task  2-3  Target  Interrogation 


In  task  2-3  the  4  DO's  use  the  INT-7  device  to  interro¬ 
gate  the  targets  located  in  task  1-2.  If  training  were  to  be  given  on 
only  this  task  (interrogation) ,  the  radar  and  target  simulation  would  be 
necessary  and,  in  addition,  some  method  of  providing  the  INT-7  device. 

From  examination  of  the  characteristics  of  the  INT-7  device  and  dis¬ 
cussions  with  both  system  engineers  and  training  device  engineers,  it 
is  determined  that:  (l)  the  INT-7  system  may  not  be  procured  for  training 
installation,  and  (2)  the  system  may  be  simulated  with  sufficient  fidelity 
for  significantly  less  cost  than  the  operational  system. 

It  is  further  determined  that  a  Type  II  power  supply 
would  also  be  adequate  for  a  device  incorporating  these  units. 

•  Task  3-4  Target  Classification 

Operationally,  the  target  classification  is  accomplished 
at.  a  Mk  1  Classification  Console.  The  console  provides  for  the  push 
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button  entry  of  target  information.  After  a  detailed  examination  of  the 
task,  it  is  determined  that,  again  in  this  case  as  in  task  2-3,  the 
necessary  elements  of  the  training  environment  may  be  provided  by  a 
simulation  of  the  Mk  1  Classification  Console.  The  simulation  used 
includes  the  information  entry  capability  and  the  essential  feedback 
indications  to  the  operator.  This  unit  may  be  referred  to  as  a  Mk  1 
C.  C.  Feedback  Simulator.  Since  this  unit  is  the  only  one  in  the  device 
necessary  to  train  task  3-4,  a  Type  I  power  supply  is  deemed  to  be 
adequate  by  costing  engineers. 

.  Task  3-3  Post  on  CP  Status  Board 


Training  for  the  status  board  operator  requires  only 
verbal  inputs;  it  does  not  require  any  equipment  other  than  a  free  com¬ 
munication  circuit.  The  entry  is  made  in  the  cost  table  "no  equipment 
required." 

.  Task  4-3  Report  Classificat:  > 

Based  on  the  performance  estimates,  no  improvement 
is  made  through  training.  No  training  is  considered  for  this  task; 
therefore,  there  are  no  equipment  requirements. 

.  Task  3-6  Evaluation  of  Threat  and  Force  Availability 


The  evaluation  of  threat  by  the  Air  Threat  Coordinator 
is  based  on  verbal  communication  from  the  Classification  Console  Opera¬ 
tor.  The  determination  of  force  availability  is  accomplished  at  the  Force 
Deployment  Console.  The  determination  is  made  that  a  simulation  of  the 
Force  Deployment  Console  will  provide  the  necessary  training  situation 
for  this  task.  Engineers  estimate  that  a  Type  I  power  supply  would  be 
adequate  for  this  equipment. 
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Task  6-7  Force  Assignment 


No  training  is  considered  for  this  task. 


b.  Estimating  Costs 


The  range  of  equipment  required  for  all  tasks  is  listed  below: 
Task  Equipment  Required 

1- 2  ALQ-85  radar  simulator,  4  radar  target 

generators,  Type  II  power  supply 

2- 3  ALQ-85  radar  simulator,  4  radar  target 

generators,  INT-7  simulator,  Type  II 
power  supply 

3- 4  Mk  1  Classification  Console  Feedback 

Simulator,  Type  I  power  supply 

3- 5  No  equipment 

4- 5  No  training 

5- 6  Force  Deployment  Console  Simulator, 

Type  I  power  supply 

6- 7  No  training 

It  is  established  that  one  prototype  trainer  will  be  built 
for  the  Corridor  Penetration  System.' 
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The  following  cost  data  are  obtained  from  engineering  per¬ 


sonnel  : 


1)  The  AN/ALQ-85  radar  has  been  simulated  previously— 
no  R&D  costs  are  incurred.  The  unit  cost  is  #45,000 
per  radar  for  less  then  production  quantity. 

2)  A  radar  target  generator  is  available  as  an  off-the- 
shelf,  item  at  #4,000  each  for  quantities  less  than  six. 

3)  The  required  INT-7  simulator  is  an  R&D  item.  Esti¬ 
mated  unit  cost,  in  less  than  production  quantity,  is 
#1,500.  R&D  cost  is  estimated  at  #3,500. 

4)  A  Mk  1  C.  C.  Feedback  Simulator  is  an  R&D  item. 
Estimated  unit  cost  is  #6,000.  R&D  cost  is  esti¬ 
mated  to  be  #12,000. 

5)  A  Force  Deployment  Console  Simulator  is  an  R&D 
item.  The  estimated  unit  cost  is  #6,500  with  an  R&D 
cost  of  #13,500. 

6)  A  Type  II  power  supply  is  an  off-the-shelf  item.  Cost 
per  unit  is  #3,000. 

7)  A  Type  I  power  supply  is  an  off-the-shelf  item.  Cost 
per  unit  is  #2,000. 


The  individual  costs  for  equipment  units  are  entered  in  the 
table  as  follows: 
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Task  1-2 

ALQ-85  H.  S. 

1  unit  ©  345K  ea. 

45K 

Radar  tgt,  gen. 

4  units  @  4K  ea. 

16k 

Type  II  power  supply 

1  unit  ©  3K  ea. 

3K 

Total 

64k 

Task  2-3 

ALQ-85  R.  S. 

1  unit  ©  #45K  ea. 

45K 

Radar  tgt.  gen. 

4  units  @  4K  ea. 

16k 

INT-7  Sim. 

1  unit  ©  1.5K  ea. 

+  R&D  0  3.5K 

5K 

Type  II  power  supply 

1  unit  <§  3K  ea. 

3K 

Total 

69K 

Task  3-4 

Mk  1  C.  C.  Feedback  Sim. 

1  unit  @  $  6K  ea. 

+  R&D  @  12K 

18k 

Type  I  power  supply 

1  unit  @  2K  ea. 

2K 

Total 

2CK 

Task  5-6 

FDC  simulator 

1  unit  ©  tf6.5K  ea. 

| 

+.  R&D  @  13. 5K 

f 

20K  ! 

Type  I  power  supply 

1  unit  @  2K  ea. 

2K'  | 

\ 

Total 

l 

22K  j 
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This  information  is  organized  in  the  following  manner  to  form 
the  cost  table. 


Table  3*  Corridor  Penetration  System  - 
Cost  Table  (One  Installation) 


Task  Equipment  Required 


1-2 

ALQ-85  R.S.  4  tgt. 

gen. 

Type  II  P.S 

2-3 

ALQ-85  R.S.  4  tgt. 
Type  II  P.  S. 

gen. 

INT-7  sim. 

3-4 

Mk  1  C.C,  Feedback 
P.  S. 

Sim. 

Type  I 

3-5 

No  equipment  necessary 

4-5 

No  training 

5-6 

FDC  sim.  Type  1  P. 

S. 

6-7 

No  training 

1 

1 

T~ - 

1 

{ 

1 

1 

1 
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1 
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1  O  PI 

a, 

b£ 

ms 

A  «  W 
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£h 

K 

s  fcj 

£l 

(H 

Note  that  task  3-5  is  a  task  which  can  be  trained,  but  does  not 
require  dynamic  simulation.  It  is  a  zero  cost  item  as  discussed  on 
page  90. 

4.  Iteration  Table 

The  development  of  the  iteration  table  demands  the  greatest 
care.  Although  the  mathematics  used  is  quite  simple,  the  bookkeeping 
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may  become  involved.  For  this  reason,  frequent  checks  should  be  made 
of  computations  performed  and  of  data  entered  into  the  table. 

To  follow  the  procedures  used  in  working  out  the  Corridor 
Penetration  System  example,  the  reader  should  refer  to  the  foldout  table 
at  the  end  of  this  section  (Table  4)  as  each  step  is  discussed.  Table  4 
is  the  completed  iteration  table  for  the  TAP  application  to  the  Corridor 
Penetration  System. 

.  The  Format 


The  form  of  Table  4  was  developed  to  organize  the  data 
in  the  most  expeditious  manner  for  performing  the  necessary  computations. 

It  permits  the  analyst  to  review  all  computations  after  each  iteration 
and  to  review  all  iterations  and  task  selections  when  the  table  is  complete. 

.  Table  Entries 


All  trainable  tasks  (tasks  for  which  there  is  expected 
improvement  with  training)  are  identified  and  one  column  in  the  table  is 
allotted  to  each.  The  following  data  are  entered  for  each  task: 

a.  On  line  1,  enter  the  p  value  for  each  task. 

u 

b.  On  line  2,  enter  the  p^  value  for  each  task. 

c.  On  line  3,  enter  the  t  value  for  each  task. 

u 

d.  On  line  4,  enter  the  t^.  value  for  each  task. 

e.  On  line  5i  enter  the  r  value  for  each  task. 

u 

f.  On  line  6,  enter  the  r^.  value  for  each  task. 

g.  Compute  p./p  for  each  task  and  enter  on  line  7. 

z  u 

h.  Compute  r^/ru  for  each  task  and  enter  on  line  8. 

.  Identification  of  the  Bottleneck  Task 

The  next  step  is  to  identify  the  bottleneck  task.  In 
rate  systems,  the  bottleneck  task  is  the  task  with  the  slowest 
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untrained  rate.  Thus,  the  lowest  figure  contained  on  line  5  of  the  table 
indicates  the  bottleneck  task.  In  Table  4,  the  bottleneck  task  is  task 
1-2  with  an  untrained  rate  of  5  targets  per  minute. 

4 

.  Iteration  I 


At  this  point,  the  table  contains  all  the  data  necessary 
to  perform  the  first  iteration.  The  first  step  in  the  iterative  proce¬ 
dure  is  to  compute  the  figure  of  merit  (FOM)  for  each  task.  FOM’s  are 
entered  on  line  9  of  the  iteration  table  (see  Table  4). 


Computation  of  the  FOM— In  rate  systems,  two  formulae  for 
the  FOM  are  applicable.  First,  the  bottleneck  task  is  treated  differently 
from  others  with  higher  rates.  Training  on  only  the  bottleneck  task  can 
yield  improvements  in  system  rate,  since  system  rate  is  determined  by 
the  bottleneck  task  rate.  This  fact  is  recognized  in  the  computation  of 
FOM' a.  Training  on  tasks  other  than  the  bottleneck  task  will  result  only 
in  improvements  in  system  accuracy. 

Bottleneck  Task  -  FOM — By  training  on  the  bottleneck  task, 
system  performance  can  be  improved  in  both  rate  and  accuracy.  The 
formula  for  computing  the  estimated  percentage  improvement  with  training 
(FOM)  is  given  as:* 


= 


-  1 


ru 


u 


x  100 


(1) 


Using  data  directly  from  the  rate  system  iteration  table,  the  formula  can 
be  expressed  as: 


*  The  reader  interested  in  the  derivation  of  these  formulae  should 
refer  to  NAVTRADEVCEN  1169-1,  Training  Analysis  Procedure, 
Volume  I,  Theoretical  Development. 
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^°^R8cA 


■t 


line  7  x  line  8-1 


] 


x  100 


(la) 


Nonbottleneck  Tasks  -  FOM — The  formula  for  the  nonbottleneck 
task  FOM  reflects  the  fact  that  training  on  these  tasks  yields  system 
improvement  in  accuracy  only.  It  is  given  as: 


FOM 


A  only 


100 


(2) 


Using  data  in  the  iteration  table,  this  can  be  expressed  as: 

line  7-1 


FOM 


A  only 


=  ] 


x 


100 


(2a) 


Limitations  -  Partial  Improvement — FOM's  are  computed  for  the 
critical  task  first.  However,  noncritical  tasks  may  limit  improvements  in 
rate  for  the  critical  task.  Therefore,  gains  in  rate  that  may  be  expected 
by  training  on  the  critical  task  cannot  exceed  the  difference  in  rate  be¬ 
tween  the  critical  task  and  other  tasks  in  the  system.  This  limitation  is 
taken  into  account  when  computing  the  FOM  for  the  critical  task. 


The  iteration  table  for  the  Corridor  Penetration  System  shows 
that  the  critical  task  is  task  1-2,  with  a  rate  of  5  targets  per  minute  and 
an  expected  improvement  of  10  per  minute  with  training.  Although  we  might 
expect  an  improvement  of  5  targets  per  minute  in  task  1-2,  task  5-6  has  a 
rate  of  6  targets  per  minute.  Therefore,  we  can  only  realize  an  improvement 
in  system  rate  to  a  level  of  6  per  minute  because  of  the  bound  imposed  by 
task  5-6. 


In  the  computation  of  the  FOM  for  task  1-2,  the  formula  is 


applied : 


FOM 


'£t_ 

^t_ 

-  1 

or 

1.00  .  4  -  1 

p 

r 

5 

-  U 

u 

m  - 

=  .20 
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The  value  of  6  used  for  represents  the  limiting  value 
imposed  by  task  5-6.  Thus,  we  realize  only  a  20  per  cent  improvement 
when,  without  the  limitation,  we  would  have  expected  100  per  cent  im¬ 
provement. 


Cost  Entries — When  all  FOM's  have  been  computed  and  entered 
in  the  table,  the  cost  data  are  entered.  The  total  costs  per  task  as 
computed  in  the  cost  table  (expressed  in  thousands  of  dollars)  are  entered 
on  line  10  for  each  task  (see  Table  4) . 

FOM/Cost  Ratio — The  FOM/cost  ratio  is  the  index  on  which  . 
the  final  results  of  a  TAP  application  are  based.  This  index  represents 
the  "payoff"  per  dollar  invested  in  training  equipment.  Payoff  is  in 
terms  of  the  greatest  benefit  to  system  performance  per  training  dollar. 
The  next  step  in  the  analysis  is  to  compute  the  FOM/cost  ratio  for  each 
task. 


Selection  of  the  First  Task — After  FOM/cost  ratios  are 
computed  for  all  tasks,  the  first  task  is  selected  for  training.  The 
task  selected  for  training  on  every  iteration  is  the  task  with  the 
highest  FOM/cost  ratio.  This  rule  applies  whether  or  not  the  task  with 
the  highest  ratio  is  the  bottleneck  task.  The  highest  ratio  indicates 
the  greatest  benefit  to  system  performance,  whether  the  benefit  be  in 
rate  alone,  rate  and  accuracy,  or  accuracy  only. 

See  Table  4.  The  zero  cost  task,  task  3-5 1  has  a  ratio  of 
infinity  and  is  selected  along  with  task  3-4  which  has  the  highest  ratio, 
1.53.  Zero  cost  tasks  are  always  selected  on  the  first  iteration  along 
with  the  first  task.  Zero  cost  tasks  are  indicated  by  the  unfilled  or 
outline  symbol  as  contrasted  with  cost  tasks  indicated  by  the  solid 
symbol . 
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After  the  task  with  the  .highest  FOM/cost  ratio  has  been 
selected  on  the  first  iteration,  it  is  removed  from  further  consideration, 
and  the  remaining  tasks  are  examined  for  the  effects  of  the  first  selection. 

The  first  determination  to  make  is  whether  system  rate  has 
changed.  In  rate  systems  this  determination  is  made  quite  simply: 

a.  If  the  task  selected  for  training  on  the  previous 
iteration  was  the  critical  task,  system  rate  may 
have  changed. 

b.  If  the  task  selected  on  the  previous  iteration  was 
not  the  critical  task,  the  system  rate  will  not  have 
changed. 

In  the  Corridor  Penetration  System,  task  3-^  which  was 
selected  was  not  the  critical  task.  Providing  training  for  this  task 
does  not  change  system  rate.  Therefore,  on  the  second  iteration  task 
1-2  is  still  the  critical  task. 

Computation  of  the  FOM — The  next  step  in  the  second 
iteration  is  to  compute  the  IOM  for  each  task.  The  procedures  used  in 
Iteration  I  apply.  However,  some  rules  of  thumb  may  be  noted: 

a.  If  the  task  selected  in  the  previous  iteration 
was  a  noncritical  task,  FOM's  remain  the  same. 

b.  If  the  task  selected  in  the  previous  iteration 
was  the  critical  task,  and  its  r, /r  ratio  was 
1.0,  FOM's  remain  the  same. 

c.  If  the  task  selected  in  the  previous  iteration 

was  the  critical  task,  and  its  r./r  ratio  was 

t  u 

greater  than  1.0,  recompute  the  FOM's. 
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It  is  particularly  important  to  recognize  when  the  critical 
task  changes,  that  is,  when  a  different  task  becomes  the  critical  task,  in 
order  that  the  appropriate  FOM's  be  used  on  the  succeeding  iteration. 

Cost  Changes — The  TAP  method  recognizes  and  accounts  for  the 
possible  common  equipment  requirements  between  tasks.  It  is  in  the  second 
iteration  that  this  consideration  is  first  made.  The  effects  of  "buying 
equipment"  for  the  first  task  selected  are  examined  for  any  possible  re¬ 
duction  in  cost  for  tasks  in  succeeding  iterations. 

The  format  of  the  cost  table  (Table  3)  was  designed  with 
these  effects  in  mind.  It  permits  the  rapid  recognition  of  cost  changes 
from  iteration  to  iteration. 

The  first  step  in  the  examination  of  the  data  for  possible 
cost  changes  is  to  indicate  the  equipment  units  which  were  "bought"  for 
the  task  selected  on  the  first  iteration.  Before  the  cost  data  are  entered 
for  each  task  on  the  second  iteration,  the  question  must  be  asked  "Does 
this  task  have  any  equipment  requirements  in  common  with  the  task  selected 
on  the  previous  iteration?"  Where  commonalities  do  exist,  the  cost  data 
entered  for  the  task  is  reduced  by  the  cost  of  the  common  equipment.  For 
example,  on  the  first  iteration  of  the  Corridor  Penetration  System,  tasks 
3-4  and  3-5  were  selected  for  training.  Equipment  for  task  3-4  included 
the  Mk  1  C.  C.  Feedback  Simulator  and  two  Type  I  power  supplies.  Task 
5-6  also  requires  a  Type  I  power  supply.  Note  that  in  the  second  iteration, 
line  13  (Table  4),  the  cost  for  task  5-6  has  been  reduced  by  #2,000,  the 
cost  of  the  Type  I  power  supply. 

Note  the  change  in  cost  for  task  2-3  between  the  third  and 
fourth  iterations  (lines  l6  and  19) .  Task  1-2  is  selected  for  training 
on  the  third  iteration.  All  of  the  equipment  required  for  task  2-3  with 
the  exception  of  the  INT-7  simulator  was  "bought"  for  task  1-2.  Thus, 
on  the  fourth  iteration  the  cost  for  task  2-3  is  reduced  by  #64,000,  the 
total  cost  of  task  1-2.  This  left  a  remainder  of  #5)000,  the  entry  on 
line  19. 
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In  many  cases  different  tasks  have  identical  equipment 
requirements,  and  when  one  of  these  tasks  is  selected  for  training,  the 
cost  for  the  other  is  reduced  to  zero.  Consequently,  with  a  cost  of  zero 
the  FOM/cost  ratio  is  infinity,  and  these  tasks  are  the  next  to  be  selected. 


Computation  of  the  FOM/Cost  Ratio — Having  computed  new  FOM's 
and  entered  new  costs,  the  next  step  is  to  compute  new  FOM/cost  ratios. 
These  ratios  determine  the  task(s)  with  the  next  greatest  benefit  to 
system  performance  per  training  dollar.  Again,  the  task  with  the  highest 
ratio  is  selected,  whether  it  is  the  bottleneck  task  or  not. 


5.  Table  of  Results 

The  iterative  procedure  is  continued  until  all  tasks  have  been 
"trained"  and  removed  from  consideration.  The  order  of  tasks  selected, 
from  the  first  iteration  to  the  last,  constitutes  the  ranking  of  tasks  in 
order  of  their  benefit  to  system  performance  per  training  expenditure. 

The  most  effective  graphic  technique  for  presenting  the  results  of  this 
analysis  is  shown  in  Figure  12.  This  plot  shows  system  improvement  as 
a  function  of  cost.  The  points  on  the  curve  represent  the  tasks  selected, 
and  they  are  plotted  as  a  step  function. 


Results  plotted  in, this  form  provide  guidelines  in  making  the 
following  fundamental  judgments  about  training  device  requirements  for  a 
system: 


a.  If  training  is  provided  for  all  tasks  in  the  system,  what 
percentage  of  system  improvement  can  be  expected,  and  what 
will  it  cost? 


b.  If  budgetary  limitations  will  not  permit  every  task  in  the 
system  to  be  trained,  which  tasks  should  be  trained  within 
the  limitation,  and  what  is  the  expected  system  improvement 
with  this  training? 
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c.  Even  vdthout  budgetary  limitations,  are  there  points 
at  which  further  expenditures  do  not  yield  commensurate 
improvement  in  system  performance? 

TAP  cannot  make  these  decisions  for  the  analyst,  but  this 
simple  graphic  presentation  will  aid  in  making  sound  recommendations. 


Figure  12.  Corridor  Penetration  System — System 
Improvement  as  a  Function  of  Cost 
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liable  4.  i 

Corridor  Penetration  System— Iteration  Table 
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E.  Fixed  Sequence  Systems  -  Procedures 

A  fixed  sequence  system  is  one  in  which  no  task  can  be  repeated 
until  the  preceding  task  in  the  sequence  is  completed,  and  the  system 
itself  cannot  recycle  until  the  last  task  is  completed.  Typically,  in 
this  type  of  system,  each  task  produces  an  output  which  is  also  the 
necessary  input  for  one  or  more  tasks.  The  purpose  of  this  subsection 
is  to  illustrate  the  procedures  for  handling  fixed  sequence  systems. 

A  simplified  hypothetical  system  will  be  carried  through  the  five  TAP 
steps.  The  reader  should  refer  to  the  foldout  (Table  7)  at  the  end  of 
this  subsection  as  each  step  is  discussed. 

1.  Network 


Consider  a  simple  example  in  which  the  following  is  a  segment 
of  a  system  description  for  the  hypothetical  "Tracer  System."  (This 
segment  will  serve  throughout  this  section  as  the  basis  for  demonstrating 
the  development  of  the  necessary  data,  the  processing  of  the  data,  and 
the  results  which  may  be  derived  from  this  analytic  technique.) 

"...The  target  is  then  entered  at  Display  Console  (DC) 

#3*  The  DC  #3  operator  applies  a  tracer  to  the  target. 

When  the  DC  #3  operator  determines  that  the  tracer  is 
secure,  he  signals  READY  TO  TRANSFER  (RTT)  with  a  foot 
switch  to  the  DC  #4  operator  and  notifies  the  Integra¬ 
tion  Console  operator  via  intercom.  Upon  receipt  of 
the  RTT  signal,  the  DC  #4  operator  sets  up  the  appro¬ 
priate  quadrant  for  transfer  and  signals  READY  TO 
RECEIVE  (RTR)  via  a  foot  switch.  The  Integration 
Console  operator  evaluates  all  four  quadrants  for 
possible  conflict.  When  conditions  are  clear,  he 
pushes  the  transfer  button.  The  target  is  then  trans¬ 
ferred  to  DC  #4. . ." 
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From  this  descriptive  passage  we  can  identify  ten  tasks  involving  three 
operators.  This  operation  would  be  diagrammed  as  below  in  Figure  13, 
Tracer  System  Network. 


Secure  RTT  Transfer 


Sval. 


Figure  13 .  Tracer  System  Network 


An  "event,"  as  depicted  by  circled  numbers  in  the  figure  above, 
is  defined  as  the  beginning  and/or  end  of  a  specific  task  or  activity  m 
the  system  operation.  The  lines  joining  events  represent  tasks.  The 
tasks  are  denoted  by  the  two  event  numbers  which  they  link,  as  13-14, 
15-16,  etc.  It  should  be  noted  at  event  15  that  information  is  trans¬ 
mitted  to  two  different  stations.  In  the  network  then,  two  paths 
emerge  which  represent  the  parallel  or  simultaneous  activities  of  two 
operators.  Also  note  that  activity  20-21  (an  automatic  or  machine  task) 
cannot  take  place  until  tasks  18-20  and  19-20  are  both  complete.  When 
analyzing  a  system,  it  is  important  to  note  such  conditional  activities. 
It  is  also  important  to  include  machine  activities  in  the  network  when 
they  provide  necessary  continuity  between  operator  activities. 
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2 .  Task  Table 


'The  tasks  identified  are  collected  in  a  list,  as  below: 
^ask  #  Task  Description 


12-13 

DC  it 3  enters  target 

13-14 

DC  #3  applies  "tracer" 

14-15 

DC  #3  determines  "tracer  secure" 

15-16 

DC  #3  signals  RTT  to  DC  #4 

15-17 

DC  #3  voice  call  RTT  to  IC  operator 

16-18 

DC  #4  auadrant  setup 

17-19 

IC  operator  quadrant  evaluation 

18-20 

DC  #4  signals  RTR 

19-20 

IC  operator  pushes  TRANSFER 

20-21 

Target  transfers  to  DC  #4 

The  next  step  in  the  development  of  the  task  table  is  to  make 
estimates  of  performance  for  trained  and  untrained  operators  for  each 
task. 

For  each  task  in  the  list  shown,  estimates  are  made  for  prob¬ 
ability  of  accurate  performance  by  untrained  operators  (pu) ,  probability 
of  accurate  performance  by  trained  operators  (p^.),  time-to-perform  for 
untrained  operators  (t^),  and  time-to-perform  for  trained  operators  (t^). 
The  task  table  takes  the  form  shov/n  in  Table  5« 

For  this  hypothetical  system,  suppose  the  following  sources 
of  information  are  available: 

a.  A  preliminary  system  operation  manual. 

b.  System  design  engineers. 

c.  A  training  installation  which  trains  on  tasks 
12-13,  13-14,  14-15. 
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Table  5  0 

Task  Table — Tracer  System 


Task 

p 

u 

pt 

tu 

*t 

12-13 

• 

Oo 

VJ1 

1.0 

.95,  1.0 

7 

6 

13-14 

.95 

.99 

6 

6 

14-15 

.75 

.98 

12 

12 

15-16 

1.0 

1.0 

2 

2 

15-17 

1.0 

1.0 

2 

2 

16-18 

.35 

.99 

30 

18 

17-19 

.95 

.99 

10 

5 

18-20 

1.0 

1.0 

2 

2 

19-20 

1.0 

1.0 

2 

2 

20-21 

2 

2 

Task  12-13  -  A  Repetitive  Task 

From  the  system  description  and  interviews  with  system 
design  personnel,  it  is  determined  that  task  12-13  involves  the  detection 
of  a  target  on  a  radar  scope  and  the  pressing  of  an  ENTRY  button  on  the 
console . 
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Accuracy  Estimates — The  task  is  a  repetitive  task  in  that 
it  must  be  repeated  until  performed  successfully — task  15-14  cannot  take 
place  until  task  12-13  is  completed.  Accordingly,  there  will  be  two 
accuracy  estimates  for  task  12-13.  The  first  estimate  is  the  probability 
of  detection  on  any  given  attempt  at  the  task.  In  the  case  of  radar 
detection,  this  is  the  probability  that  the  operator  will  detect  the  target 
on  any  given  sweep.  Here,  suppose  we  learn  from  the  system  description 
that  the  operator  will  have  prior  information  on  the  general  location  of 
the  signal  on  the  jcope  as  a  result  of  previous  processing  by  the  system. 
This  fact  would  increase  any  estimate  made  for  probability  of  detection 
without  advance  information.  For  the  untrained  operator,  then,  we  assign 
a  "given  attempt"  probability  of  .85  which  says,  in  effect,  we  estimate 
that  the  operator  will  fail  to  detect  the  target  15  times  out  of  100 
sweeps.  In  addition,  we  confirm  this  estimate  by  interviews  with  per¬ 
sonnel  at  the  12-13  Training  Installation. 

In  repetitive  tasks,  however,  it  is  also  true  (by  definition) 
that  after  a  number  of  attempts  the  operator  will  successfully  complete  the 
task— giving  a  probability  of  1.0.  This  is  the  probability  of  successful 
performance  for  that  task. 

These  estimates  (.85,  1.0)  are  entered  in  the  table  as  the 
Pu  values  for  task  12-13.  After  discussion  with  personnel  at  the  12-13 
Training  Installation,  it  is  determined  that  with  practice  an  operator's 
probability  of  detection  on  a  given  sweep  is  .95*  His  task  probability 
is,  again,  1.0.  These  figures  are  entered  in  the  table  as  the  p^_  values 
for  task  12-13. 

Time  Estimates — Time  estimates  for  repetitive  tasks  follow 
the  same  general  thinking  as  accuracy  estimates.  For  task  12-13,  we  must 
first  estimate  the  amount  of  time  required  to  perform  the  task  if  it 
were  performed  satisfactorily  on  any  given  attempt.  Since  we  have 
estimated  =  .85  on  one  sweep,  obviously  this  task  can  be  performed 
in  one  sweep.  From  the  system  design  engineers,  we  establish  a  standard 
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antenna  rotation  rate  of  10  rpm  for  the  radar  being  used.  An  opera¬ 
tor  can  then  perform  the  task  in  6  seconds.  This  is  the  time  per  given 
attempt.  This  completion  time  is  achieved  with  a  probability  of  only 
.85  (untrained  accuracy  per  given  attempt).  V/e  then  must  calculate  an 
expected  time  for  completion  over  a  large  number  of  trials.  This  is 
done  by  dividing  the  time  on  a  given  attempt  b.v  the  probability  of  success 
on  that  attempt.  In  this  case  it  is  6  seconds  divided  by  .85i  or  7 
seconds.  Thus,  7  seconds  is  the  expected  task  completion  time. 

The  estimated  time  per  given  attempt  for  the  trained 
operator  is  also  one  sweep  or  6  seconds.  The  expected  time  for  a  trained 
operator  is  6  seconds  divided  by  .95*  Rounded  off,  this  is  also  6  seconds. 

Thus,  for  the  t  and  t,  values  of  task  12-13,  we  enter  7  and 
u  t 

6  seconds,  respectively  (see  Table  3) • 

Task  13-14  -  A  Nonrepetitive  Task 


Task  13-14  is  a  nonrepetitive  task.  System  information 
indicates  that  the  application  of  the  "tracer"  by  the  DC  #3  operator 
involves  superimposing  a  coded  symbol  over  the  target  by  means  of  a  joy- 
stick.  The  operator  will  perform  che  task  only  once,  and  the  system  will 
operate  on  whatever  data  are  provided  by  this  action  regardless  of  its 
quality.  For  this  reason,  it  is  a  nonrepetitive  task.  The  system  has 
an  error  tolerance  for  the  positioning  of  the  symbol  with  respect  to  the 
target.  If  the  symbol  is  positioned  by  the  operator  within  acceptable 
limits,  the  data  provided  will  permit  the  system  to  function  effectively 
in  subsequent  steps.  If  the  positioning  exceeds  tolerable  limits,  the 
system  will  continue  to  function  but  will  be  operating  on  out-of-tolerance 
data.  From  the  12-13  training  personnel,  it  is  determined  that  novices 
can  perform  this  operation  within  acceptable  limits,  95  times  out  of  100. 
V/e  assign  a  value  of  .95  as  the  p^  for  task  13-14.  From  the  same  source 
it  is  further  determined  that,  with  practice,  this  performance  improves  to 
.99.  This  is  the  p^  value  for  task  13-14.  These  figures  are  entered  in 
the  table  (see  Table  5) • 
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A  time  estimate  for  a  nonrepetitive  task  is  simply  the 
time-to-perform  for  tliat  task .  In  this  case  it  reau  Ires  an  average  of 
one  sweep  on  the  radar  to  accomplish  symbol  positioning.  We  establish 
that  both  trained  and  untrained  operators  will  perform  in  6  seconds. 
Entries  of  6  seconds  are  made  in  the  table  for  t  and  t  for  task  13-14. 

U  1/ 

Task  14-13 


The  task  is  described  as  "DC  #3  operator  determines  tracer 
secure."  It  is  learned  from  system  designers  that  this  task  requires 
the  operator  to  determine,  in  two  sweeps,  that  the  system  has  "locked 
on"  to  the  target  sufficiently  to  effect  a  target  transfer.  This 
involves  a  perceptual  judgment  of  successive  error  between  the  target 
and  the  coded  symbol  on  each  sweep.  Error  tolerances  are  small  and  the 
judgment  is  precise. 

Accuracy  of  performance  for  this  task  is  enhanced  sig¬ 
nificantly  with  practice.  Training  personnel  indicate  that  new  trainees 
make  this  judgment  correctly  only  75  times  out  of  ICO.  However,  with 
practice  these  judgments  are  made  correctly  with  a  probability  of  .98. 

Time-to-perform  in  task  14-15  is  determined  by  operating 
procedures — the  judgment  is  made  in  two  sweeps.  Thus  for  both  trained 
and  untrained  operators,  times  are  12  seconds  (see  Table  5). 

Task  15-16 


This  task  is  nonrepetitive.  It  is  a  simple  foot-switching 
operation.  It  has  no  evaluative  aspects;  the  evaluation  is  made  in  the 
previous  task,  14-15.  The  likelihood  that  the  operator  will  depress  the 
foot  switch  when  not  ready  to  transfer  or  that  he  will  not  depress  it 
when  ready  is  negligible.  Therefore,  accuracy  for  both  trained  and 
untrained  operators  is  1.0.  Similarly,  the  time  taken  to  perform  this  task 
cannot  be  improved  with  practice.  It  is  estimated  that  the  action  takes 
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2  seconds  (see  Table  5)»  Task  15-16  is,  in  a  sense,  an  "untrainable 
task,1'  i.e.,  no  improvements  in  performance  can  be  gained  with  training 
(see  Table  5). 

.  Task  15-1? 


Simultaneously  with  task  15-16,  the  operator  voice  calls 

"ready  to  transfer"  to  the  Integration  Console  operator.  The  same 

rationale  as  used  in  task  15-16  is  applied  to  this  simple  reporting 

task.  Both  p  and  p.  are  1.0  and  times  are  2  seconds,  trained  and 
*u 

untrained. 

Task  16-18 


In  task  16-18 ,  the  DC  #4  operator  accomplishes  a  setup 
routine  for  a  single  quadrant  display  involving  a  number  of  steps  to 
prepare  the  equipment.  In  tasks  of  this  type  (setup  and/or  checkout 
sequences)  the  several  routine  steps  are  collected  under  one  task  title. 
Accuracies  may  vary  widely  depending  upon  the  intricacy  and  length  of  the 
procedure.  System  designers  indicate  that  task  l6-l8  is  mainly  a  series 
of  six  simple  button- pushing  operations  and  one  cursor-positioning  step. 

A  consensus  of  estimates  from  designers  and  TSA  personnel  gives  a 
probability  of  .35  for  unpracticed  operators  and  .99  for  practiced  per¬ 
formance. 


A  simple  check  with  a  stop  watch  on  several  analysts  going 
through  a  representative  set  of  motions,  plus  some  intuition  with  regard 
to  the  effects  of  training,  yields  time  estimates  of  50  seconds  for  t^ 
and  18  seconds  for  t^. 

.  Task  17-19 


Task  17-19  is  nonrepetitive.  The  Integration  Console 
operator  performs  an  evaluative  function  in  this  system.  His  task 
involves  comparing  coded  symbols  in  each  of  four  quadrant  displays 
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^  and  applying  decision  rules  based  upon  the  quantities  displayed.  This 

operator  is  a  senior  member  of  the  processing  team,  and  the  task  requires 
extensive  experience  in  the  area.  We  determined  from  system  design 
personnel  that  the  decisions  made  here  are  not  unlike  decisions- made  in 
this  system's  predecessor.  The  task  differs  only  in  the  form  of  the 
display  and  the  symbology  employed.  Further,  we  anticipate  that  the 
operator  in  task  17-19  will  most  likely  be  a  transferee  from  the  old 
system.  In  this  case,  it  is  necessary  to  interview  operating  personnel 
in  the  old  system  to  establish  realistic  estimates  of  performance  for 
the  task. 

Based  on  such  interviews ,  it  is  determined  that  the 
counterpart  task  in  the  old  system  was  accomplished  with  an  accuracy  of 
.90  untrained,  and  was  improved  to  .97  with  practice.  However,  discussions 
reveal  that  the  task  requirements  of  17-19  are  somewhat  simplified  by  the 
new  display  form.  The  accuracy  estimates  for  17-19  are  modified  accord¬ 
ingly,  and  the  final  estimates  are  .95  and  .99. 

i 

Time  estimates  derived  in  a  similar  manner  are  15  seconds 
and  10  seconds  in  the  old  system,  revised  to  10  seconds  and  5  seconds  for 

17-19.. 

.  Task  18-20 

Task  18-20  is  a  nonrepetitive  task  identical  to  15-16 — a 
simple  foot-switching  operation  denoting  completion  of  the  previous  task. 
The  same  values  used  for  15-16  are  used  for  18-20. 

.  Task  19-20 

Task  19-20  is  a  nonrepetitive  task— a  simple  button¬ 
pushing  operation.  Again,  the  same. values  are  used  as  for  15-16. 
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Task  20-21 


Task  20-21  is  a  "machine"  task.  It  is  accomplished  by  the 
electronic  computer  in  the  system  and  cannot  be  trained.  However,  it  is 
included  in  the  network  to  maintain  continuity  of  information  flow  and 
activity  sequence,  and  to  maintain  accurate  system  time  estimates. 

A  time  estimate  is  made  for  the  target  transfer  denoted  by 
20-21  since  it  affects  total  system  time,  i/e  assign  a  time  of  2  seconds. 

The  entry  of  these  figures  completes  the  task  table. 

3.  Cost  Table 


To  demonstrate  fully  the  procedures  used  in  developing  initial 
cost  data  in  TAP,  the  Tracer  System  data  are  worked  out  in  detail  in  the 
following  sections.  The  procedures  for  determining  cost  changes  in  the 
iterative  analysis  are  discussed  under  "Cost  Changes,"  page  163.  Although 
the  determination  of  equipment  requirements  per  task  is  not  part  of  the 
TAP  procedures,  this  step  is  illustrated  for  the  Tracer  System  example. 

The  purpose  of  this  illustration  is  mainly  to  show  the  form  in  which  the 
requirements  are  stated  for  use  in  TAP. 

a.  Equipment  Required 
.  Task  12-13 


Task  12-13  is  basically  a  radar  detection  task  utilizing 
a  repeater  (DC  #3  console)  displaying  the  "AN/XYZ-99"  radar.  The  operator 
is  never  required  to  deal  with  more  than  one  target  at  a  time.  Targets 
appear  in  range  and  bearing  only.  The  equipment  necessary  for  training 
operators  in  this  particular  detection  task  is  a  radar  simulator  for  the 
XYZ-99;  a  single,  range-and-bearing-only,  target  generator;  a  Type  I 
power  supply;  and  a  GFE  DC  #3  console.  At  this  point,  a  requirement  has 
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been  established  for  three  different  training  device  "units.”  In  this 
case,  the  training  device  is  intended  for  a  shipboard  installation  feeding 
directly  to  existing  operational  units.  In  such  instances  the  operational 
equipment  is  not  considered  in  the  cost  analysis.  If,  however,  the  pro¬ 
posed  device  is  intended  for-  an  installation  where  Gj?T3  would  have  to  be 
procured,  the  costs  of  the  necessary  procurement  must  be  included  in 
the  analysis. 


Task  13-14 


Task  13-14  is  also  performed  at  the  DC  #3  console  which 
repeats  the  AN/XYZ-99  radar.  This  task  differs  from  task  12-13  in  that 
the  operator  must  maneuver  a  coded  symbol  with  respect  to  the  target. 

In  addition  to  the  requirements  of  12-13,  a  symbol  or  character  generator 
is  necessary. 


Task  14-13 


Task  14-15  is  performed  at  DC  #3  using  the  same  display 
information  as  task  13-14.  It  has  the  same  equipment  requirements  as 
task  13-14. 


Task  15-16 


Note  in  the  task  table  (page  138)  that  performance  on  task 
15-16  cannot  be  improved  with  training.  Therefore,  it  need  not  be 
examined  further.  No  cost  estimates  are  made. 

Task  15-17 


Same  as  task  15-16 — no  estimates  made. 


145 


NAVTRADEVCZN  1218-4 


Task  16-18 


Task  l6-l8  is  performed  at  DC  #4 — a  setup  sequence  which 
prepares  the  console  for  target  transfer.  During  the  setup  sequence,  the 
display  repeats  one  quadrant  of  the  AN/XYZ-99  display.  In  this  case,  in 
addition  to  a  radar  simulator,  a  feedback  device  is  required  which  will 
provide  the  necessary  sequence  of  indications  to  the  operator  as  he 
steps  through  the  procedure.  Under  "equipment  required"  for  task  16-18, 
an  XYZ-99  radar  simulator  and  a  "DC  #4  setup  simulator"  are  listed.  A 
DC  #4  setup  simulator  as  required  does  not  presently  exist.  Therefore, 
in  consultation  with  engineers,  the  cost  of  developing  the  unit  must  be 
determined. 


Task  17-15 


Task  17-19  is  performed  at  the  Integration  Console  which 
includes  four  separate,  expanded  displays  of  each  quadrant  of  the  ANAYZ-99. 
The  operator  must  evaluate  as  many  as  four  targets  simultaneously,  all  in 
conjunction  with  their  coded  symbols. 

The  equipment  requirements  for  this  task  include  four 
target  generators  (of  the  type  to  be  used  for  task  J2-1J),  an  AN/XYZ-99 
simulator,  and  either  a  four-channel  character  generator  or  four  separate 
character  generators.  The  latter  choice  will  be  made  on  the  basis  of 
cost  and  feasibility  estimates  by  the  engineers.  It  is ^also  determined 
that  the  Type  I  power  supply  is  satisfcctory  for  this  device. 

.  Task  18-20 


Again,  this  is  a  task  which  cannot  be  improved  with  training 
(see  Table  5)«  No  estimates  are  made. 

.  Task  19-20 


No  estimates  are  made  (see  Table  5) • 
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Task  20-21 


No  estimates  are  made  (see  Table  5) . 

Having  examined  each  task  in  terms  cf  the  equipment  required 
to  train  that  task,  the  next  step  in  the  development  of  the  coot  table  is 
to  obtain  cost  estimates  and  prepare  an  itemized  cost  list  for  the 
necessary  equipment. 

b.  Estimating  Costs 


The  range  of  equipment  required  for  all  tasks  includes  five 
distinct  units;  an  AN/XYZ-99  radar  simulator,  a  range-and-bearing-only 
target  generator,  a  character  generator,  a  DC  #4  setup  simulator,  and 
a  Type  I  power  supply.  These  requirements  are  summarized  in  the  list 
below. 


Task 

Equipment  Required 

12-13 

XYZ-99  R.S.,  rb  tgt.  gen., 

Type  I  P.S. 

13-14 

XYZ-99  R.S.,  rb  tgt.  gen., 

Character  Gen.,  Type  I  P.S. 

14-15 

XYZ-99  R.S.,  rb  tgt.  gen., 

Character  Gen.,  Type  I  P.S. 

15-16 

No  Training 

15-17 

. No  Training 

16-18 

XYZ-99  R.S.,  DC  #4  setup 

sim. ,  Type  I  P.S. 
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17-19 


18-20 

19-20 
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XYZ-99  S.S.,  four  rb  tgt. 
gen.,  four  channel  character 
gen.,  Type  I  P.S. 


No  Training 
No  Training 


20-21  No  Training 


Cost  Estimates 


It  is  established  that  two  trainers  of  this  type  will  be 
built,  as  shore-based  installations. 

The  following  cost  data  are  obtained  from  cost  estimators 
(usually  engineering  personnel) : 

1)  The  AN/XYZ-99  radar  has  been  simulated  previously; 
no  R  St  D  costs  are  incurred.  The  unit  cost  is 
#25,000  per  radar  for  less  than  production  quantity. 

2)  A  range-and-bearing-only  target  genex-ator  is  avail¬ 
able  as  an  off-the-shelf  item  at  #4,000  each  for 
quantities  less  than  6.  For  quantities  of  6  or 
more,  the  unit  cost  is  #1,250  each. 

3)  A  character  generator  of  the  type  required  is  an 
R&D  item.  Estimated  unit  cost,  in  less  than 
production  quantity,  is  #1,500.  R&D  cost  is 
estimated  at  #3,000.  A  four-channel  character 
generator  is  feasible  and  the  unit  cost  is  esti¬ 
mated  to  be  #2,500.  The  R&D  cost  is  estimated  at 
#5,000. 
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4)  A  DC  #4  setup  simulator  is  an  R8eD  item.  The  estimated 
cost  per  unit  is  *8 00  with  an  R&D  cost  of  *1,500. 

5)  A  Type  I  power  supply  is  an  off-the-shelf  item. 

Cost  per  unit  is  *1,000. 

This  information  is  organized  in  the  following  manner  to  form  the  cost  table. 

Table  6 

Cost  Table — Tracer  System 


Task 

99  H.S. 

Tgt.  Gen. 

Char.  Gen. 

DC  #4  Sim. 

P.S. 

Hdwre.  Total 

12-13 

50K 

8K 

- 

- 

2K 

60K 

13-14 

50K 

8K 

6K 

- 

2K 

66K 

14-15 

50K 

8k 

6K 

_ 

2K 

66k 

15-16 

15-17 

i 

16-18 

50K 

- 

- 

3. IK 

2K 

55. IK 

17-19 

50K 

10K 

10K 

2K 

72K 

18-20 

19-20 

20-21 
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The  individual  costs  for  equipment  units  are  entered  in 
the  tabla  as  follows: 

Task  12-13 


XYZ-99  R.S. 

2  units  @  # 2 5K  ea.  —  50K 

rb  tgt.  gen. 

2  units  <8  4K  ea.  —  8K 

Type  I  P.S. 

2  units  @  IK  ea.  —  2K 

• 

Total 

60K 

Task  13-14 

XYZ-99  R.S. 

2  units  <3  i2%  ea.  —  50K 

rb  tgt.  gen. 

2  units  @  4K  ea.  —  8K 

char.  gen. 

2  units  <8  1.5K  ea. 

plus  R&D  ®  3K  —  6K 

Type  I  P.S. 

2  units  @  IK  ea.  —  2K 

Total 

66K 

Task  14-15 

Same  as  13-14 

Task  16-18 

XYZ-99  R.S. 

2  units  <8  #25K  ea.  —  50K 

DC  #4  sim. 

2  units  @  ,8K  ea. 

plus  R&D  &  1.5K  —  3- IK  ' 

Type  I  P.S. 

2  units  <8  IK  ea.  —  2K 

Total 

55. IK 
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Task  17-19 


XYZ-99  B.S. 

2  units  9  $25K  ea.  —  50K 

rb  tgt.  gen. 

8  units  @ 

1.25K  —  10K 

Char.  gen. 

2  units  <3  2.5  K  ea. 
plus  H&D  9  5K  —  10K 

Type  I  P.5. 

2  units  <3 

IK  ea.  —  2K 

Total 

72K 

4.  Iteration  Table 


In  order  to  understand  precisely  the  steps  in  the  iteration 
process,  the  reader  is  urged  to  refer  to  the  iteration  table  worked 
out  on  page  166  at  the  end  of  the  chapter  as  each  step  is  described  in 
the  text.  The  table  on  page  l66  represents  the  entire  series  of 
iterations  for  the  Tracer  System  example,  treated  as  a  fixed  sequence 
system. 


.  The  Format 

It  has  been  found  most  useful  to  follow  the  iteration 
procedure  by  organizing  the  necessary  data  in  a  table  constructed  in 
the  form  shown  in  Table  7.  This  format  permits  the  analyst  to  review 
the  results  from  iteration  to  iteration  in  a  rapid  and  efficient  manner., 

The  iteration  procedure  is  largely  an  exercise  in  simple 
arithmetic.  However,  although  the  method  is  simple,  utmost  care  must 
be  taken  in  both  computing  and  entering  data  in  the  table.  Tnere  are  .  . 
several  reasonableness  checks  that  can  be  made  at  various  stages — and 

i 

all  figures  should  be  checked  after  each  iteration  before  proceeding  to 
the  next  one. 
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Identification  of  Paths 


In  the  preparation  of  the  iteration  table,  one  must  account 
for  all  the  alternate  paths  in  the  system  network,  i.e.,  all  paths  must 
be  represented  in  the  table .  Each  path  represents  an  independent  sequence 
of  activity  and  information  flow  through  the  system,  leading  to  a  system 
output.  Figure  14  on  page  153  illustrates  paths  in  several  different 
kinds  of  system  networks. 


The  Tracer  System  has  two  paths  (see  Figure  1?).  Path 
A  includes  tasks  12-13,  13-14,  14-15,  15-16,  16-18,  18-20,  and  20-21. 
Path  B  includes  tasks  12-13,  13-14,  14-15,  15-1?,  17-19 ,  19-20  and 
20-21. 


Identification  of  Trainable  Tasks 


For  each  path  identified,  list  the  tasks  in  that  path. 

In  each  list,  indicate  the  "untrainable"  tasks,  i.e.,  machine  tasks  or 
tasks  for  which  there  is  no  expected  improvement  with  training.  In 
Figure  17  (page  166)  these  tasks  are  15-16.  15-17 ,  18-20,  19-20,  and 
20-21.  For  each  path,  compute  the  sum  of  the  untrained  time  estimates 
(tu>  for  the  "untrainable"  tasks  which  are  entered.  This  sum  may  be 
called  "K".  In  Figure  17,  the  K  for  both  path  A  end  path  B  is  6  seconds. 

For  each  untrainable  task,  indicate  the  untrained  time 

» 

estimate  (t  ).  In  each  case  in  Figure  17,  the  tu  happens  to  be  2 
seconds. 

Table  Entries 

a.  Enter  the  remaining,  or  '’trainable,"  tasks  into  the 
columns  of  the  iteration  table,  one  task  per  column. 
Every  trainable  task  in  every  path  must  be  represented 


152 


Network  Path* 


In  System  I  shown  above,  two  paths  exist: 

Path  A  -  which  includes  tasks  1*2,  2*3,  3-5,  5-6 
Path  B  -  which  includes  tasks  1-2,  2-4,  4-5,  5-6 


Network  Paths 


In  System  II,  three  paths  exist: 

Path  A  -  including  tasks  1-2,  2-3,  3-5,  5-6,  6-7 
Path  B  -  including  tasks  1-2,  2-6,  6-7 


Network  Paths 


In  System  III,  there  are  four  paths: 

Path  A  -  1-2,  2-3,  3-5,  5-6,  6-7,  7-9 

Path  B  -  1-2,  2-3,  3-5,  5-6,  6-8,  8-9 

Path  C  -  1-2,  2-4,  4-5,  5-6,  6-8,  8-9 

Path  D  -  1-2,  2-4,  4-5,  5-6,  6-7,  7-9 

Figure  14.  Multiple  Networks 
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in  the  table*  Tasks  which  are  common  to  several 
paths  are  entered  in  the  task  group  for  each  path 
in  which  they  occur. 

b.  Label  the  task  groups  for  each  path  A,  B,  etc. 

(if  appropriate). 

c.  Indicate  repetitive  tasks  with  "B"  above  the  task 
number. 

d.  On  line  1,  enter  the  pu  estimates  for  each  task. 

e.  On  line  2,  enter  the  estimates  for  each  task. 

f.  On  line  3»  enter  the  ty  estimates  for  each  task. 

g.  On  line  4,  enter  the  t^  estimates  for  each  task. 

h.  Compute  the  ratio,  p  /p  ,  for  each  task  (line  2 

t  u 

divided  by  line  1).  Enter  these  ratios  on  line  5. 

i.  Compute  the  difference,  t  -  t.  ,  for  each  task. 

U  w 

(Line  3  minus  line  4).  Enter  these  differences  on 
line  6,  labelled  At.,  Note:  When  computing  tu  - 
t-j.  ^ or  repetitive  tasks ,  the  expected  time 
estimates  should  be  used. 

j.  For  each  path,  compute  Et^u,  the  sum  of  the  untrained 
time  estimates  for  all  tasks  ?n  the  path.  This 
involves  adding  the  K  for  the  path  to  the  sum  of  t^ 
estimates  of  the  trainable  tasks  entered  in  the 
table.  Thus,  the  Stiu  for  each  path  is  the  2tu 

for  the  untrainable  tasks  (K)  plus  the  Ety  for  the 
trainable  tasks  (those  entered  in  the  table). 

Enter  the  Et.  for  each  path  on  line  7  and  circle 

1U 
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4U 


i 


the  figure.  The  Et^u  represents  "path  time." 

The  path  times  in  the  Table  7  are  6l  seconds  for 
path  A  and  4l  seconds  for  path  B.  Note:  When 
computing  Et^u  for  paths  which  contain  repetitive 
tasks,  the  expected  time  estimates  should  be  used. 

Iteration  I 


At  this  point,  the  table  contains  all  the  data  necessary 
to  perform  the  first  iteration.  The  first  step  in  the  iterative 
procedure  is  to  compute  the  figure  of  merit  (FOM)  for  all  tasks. 

Computing  the  FOM — In  fixed  sequence  systems,  several 
formulae  for  the  FOM  apply: 

First,  tasks  on  the  CSTP  (i.e.,  Critical  System  Time 
Path)  are  treated  differently  from  those  on  non-CSTP's,  It  should  be 
remembered  that  the  FOM  is  an  index  of  system  improvement  as  a  result 
of  training  on  the  task.  Since  system  operating  time  is  limited  by  the 
critical  path,  i.e.,  the  system  cannot  operate  in  less  time  than  it 
takes  to  complete  the  critical  path,  improvements  in  task  time  can 
benefit  system  time  only  when  the  task  lies  on  the  critical  path. 

This  fundamental  notion  is  reflected  in  the  FOM's  for  CSTP  and  non- 
CSTP  tasks. 

! 

CSTP  Tasks — By  training  tasks  on  the  critical  path, 
system  performance  can  be  improved  in  both  time  and  accuracy.  The 
formula  for  computing  the  estimated  percentage  improvement  with  training 
is  given  as:* 


*  for  the  reader  interested  in  the  derivation  of  these  formulae,  see 
NAVTRADEVCEN  11 69-1 ,  Training  Analysis  Procedures,  Volume  I, 
Theoretical  Development. 

✓ 

| 
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"■W  5 


T  stiu 

*U 

eT  -  t  +  t. 
iu  u  t 


-  lx  100 


where:  FOM^^  =  Figure  of  merit  for  time  and  accuracy. 

p./p  =  The  ratio  of  accuracy  estimates  for  trained 

u  U 

and  untrained  performance. 


=  The  sum  of  the  time  estimates  for  untrained  per¬ 
formance. 


t  =  The  untrained  time  estimate  for  the  task, 

u 


t^  =  The  trained  time  estimate  for  the  task. 


This  expression  can  be  reduced  to: 


f  Stiu 

ru 

Et.u  -  At 


-  l  x  100 


where : 


At  =  t  -  t 
u  t 


For  actual  computation  purposes ,  the  equation  may  be 
expressed  in  terms  directly  applicable  to  iteration  table  7- 


line  5  x  line  7  ,  /tv\ 

FOM^  non-rep.  -  ij  x  100  (Jb> 


Repetitive  Tasks  -  CSTP— It  should  be  noted  that,  for 
repetitive  tasks,  p./p  is  always  1.0  since,  by  definition,  the  task 
will  be  repeated  until  completed  successfully.  Further,  At  for  repetitive 
tasks  is  the  difference  between  expected  times  to  perform. 
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With  these  facts  at  hand,  equation  (3a)  reduces  even 
further  to  equation  (3c)  below: 


rep. 


x  100 


(3c) 


Equation  (3c)  reduces  to  equation  (3d): 


rep. 


line  7 


line  7  (path) 

(path)  -  line  fa  (task-expected) 


x  100  (3d) 


Non-CSTP  Tasks — By  training  tasks  not  on  the  critical 
path,  system  performance  can  be  improved  in  accuracy  only.  The  formula 
for  computing  the  estimated  percentage  improvement  with  training  is 
given  as: 


FOM 


A  only  = 


-1-1 

Pu 


X  100 


(2) 


For  computation  purposes,  using  the  data  directly  from 
the  iteration  table,  this  equation  may  be  expressed  simply  as: 


FOM.  ,  =  line  5  (task)  -lx  100 

A  only  |_ 


(2b) 


This  equation  is  the  same  for  both  repetitive  and  non- 
repetitive  tasks.  But  obviously  for  repetitive  tasks  P^./pu  is  always 
1.0  and  the  FOM  is  zero.  This  says,  in  effect,  that  no  improvement  in 
system  performance  can  be  expected  by  training  repetitive  tasks  that 
are  not  on  the  critical  path. 


Limitations  on  the  FOM  -  Partial  Improvement— In  actual 
practice,  FOM's  are  computed  for  the  CSTP  first.  In  computing  FOM's  for 
the  CSTP,  the  analyst  must  remember  that  each  FOM  represents  the  improve¬ 
ment  in  system  performance  that  may  be  expected  if  the  task  is  trained. 
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However,  it  should  be  kept  in  mind  that  the  system  operating  time  is 
determined  by  the  longest  path  time.  In  this  connection,  the  following 
problem  can  arise: 

If  the  gain  in  time  expected  with  training  on  a  task 
exceeds  the  difference  in  time  between  the  CSTP  and  a  noncritical  path, 
the  actual  gain  in  system  time  cannot  exceed  the  difference  in  time 
between  the  two  paths.  This  limitation  is  taken  into  account  in  com¬ 
puting  the  FOM. 


Consider  the  following  example:* 


Figure  15 .  Sample  Multipath  System. 


PATH 

A 

B 

c 

Task 

99 

2-5 

5-8 

ra 

3-6 

6-8 

■fill 

4-7 

7-8 

Hi 

mm 

.70 

.90 

.50 

.85 

.70 

.98 

.90 

9 

1 

.95 

.95 

.90 

.98 

.98 

1.0 

.95 

9 

15 

30 

15 

17 

30 

18 

10 

10 

10 

9 

5 

25 

12 

12 

20 

12 

8 

8 

8 

1.000 

1.357 

1.250 

1.056 

1.800 

1.153 

1.1*00 

1.020 

1.056 

At 

10 

5 

3 

5 

10 

6 

2 

2 

2 

m 

60 

65 

30 

*  These  data  are  not  related  to  the  Tracer  System.  They  are  presented 
for  exposition  of  this  point  only. 
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Note  that: 

1)  Path  B  is  the  CSTP  with  a  St^  of  65  seconds. 

2)  The  difference  between  Path  B  and  Path  A  is  5 
seconds . 


In  computing  the  FOM  for  task  1-3,  the  formula  is 


applied: 


.  IVpu  Etiu 

'  Ls‘i"" At  '  J 


100  =  h°%m 


■] 


x  100 


However,  in  computing  the  FOM  for  task  3-6,  it  is  noted 
that  the  At  =  10  is  greater  than  the  5  seconds  difference  between  Path 
A  and  Path  B.  Thus: 


-  ]xm 


x  100 


In  the  denominator,  the  value  of  St.  -  At  is  given  as 
60,  although  theoretically  St^y  -  At  appears  to  be  63  -  10,  or  55. 

The  denominator  of  this  expression  represents  system  operating  time 
after  training  on  task  3-6. 


We  may  expect  that  Path  B  will  be  completed  in  55  seconds 
after  training  on  task  3-6  but  system  operating  time  will  still  be  60 
seconds — determined  by  Path  A  which  would  be  the  longest  path,  if  we 
trained  task  3-6. 


Similarly,  in  computing  the  FOM  for  task  6-8,  we  apply 


the  formula: 


„  1.153(65)  .  1  x  100 
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We  can  only  realize  5  seconds  of  the  6  seconds  improve¬ 
ment  in  system  performance  in  task  6-8  with  training.  It  may  be  said 
then  that  Path  A  places  a  “bound"  on  the  improvement  in  system  per¬ 
formance  that  may  be  expected  from  training  on  tasks  in  Path  B. 

Therefore,  the  analyst  should  be  constantly  aware  of  the 
bounds  imposed  by  other  paths  on  FOM's  computed  in  the  CSTP. 

Common  Tasks  in  the  Presence  of  a  Bound — When  the 
situation  described  above  occurs  and  non-CSTP's  impose  limitations  on 
the  FOM's  for  certain  tasks,  one  condition  can  free  the  path  of  this 
limitation.  If  the  task  in  question  is  common  to  both  the  CSTP  and 
the  bounding  path,  the  limitation  does  not  apply.  Since  training  on 
the  common  task  will  result  in  a  subsequent  decrease  in  both  path  times 
(to  the  extent  of  At),  the  bound  really  does  not  exist  for  that  task. 
Thus,  in  each  case,  the  analyst  should  first  check  for  the  presence 
of  a  limiting  path  time  and,  if  it  exists,  check  for  the  commonality 
of  that  task  to  both  paths.  If  the  task  is  common  to  both  the  CSTP 
and  the  limiting  path,  the  bound  does  not  apply.  If  the  task  is  not 
common  to  both  paths,  the  limit  is  imposed  as  described  above. 

Identical  Path  Times — When  a  situation  arises  in  which 
two  oaths  have  an  identical  St.  and  both  are  the  CSTP,  the  tasks  in 

*  1U 

both  paths  are  pooled  and  treated  as  a  single  CSTP.  FOM^,^  i®  1166(1 
for  tasks  in  both  paths.  In  this  case,  the  next  nearest  path  time 
acts  as  the  bound  on  the  FOM's  computed  in  both  paths. 

Tracer  System  -  FOM's— All  FOM's  are  entered  on  line  8 
in  the  iteration  table  (see  Table  7)*  FOM's  sire  computed  in  Path  A 
first  (the  CSTP)  using  the  formula  for  FOM^^  (3).  Note  that  task 
12-13  i8  i  repetitive  task  for  which  the  FOM  is  1.7#»  FOM's  are 
expressed  in  the  table  as  percent  improvement.  Training  on  task  13-14 
would  yield  4$  improvement  in  system  performance,  task  14-15  would 
yield  and  task  16-18  would  yield  44$. 


I 
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Note  that  in  this  example,  Path  B  does  not  impose  a 
bound  on  any  of  the  FOM's  in  Path  A. 

Cost  Entries — When  all  FOM's  have  been  computed  and 
entered  in  the  table,  the  cost  data  are  entered.  The  total  costs  per 
tasks  as  computed  in  the  cost  table  (expressed  in  thousands  of  dollars) 
are  entered  on  line  9  for  each  task. 

Double  Entry— After  computing  the  FOM's  for  tasks  in 
Path  A,  the  next  step  is  to  enter  the  CSTP  FOM's  for  all  tasks  in  the 
CSTP  that  lie  on  other  paths  as  well.  In  the  example,  12-13,  13-14, 
and  14-15  are  all  common  to  the  CSTP  and  Path  3.  Their  CSTP  FOM's 
are  carried  into  the  appropriate  Path  B  cells  (see  Table  7). 

After  carrying  CSTP  FOM's  into  common  task  cells,  the 
FOM's  are  computed  and  entered  for  non-common,  non-CSTP  tasks.  In 
the  example,  task  17-19  (noted  as  NC,  at  the  head  of  the  column)  is 
the  only  non-common,  non-CSTP  task. 

Computation  of  FQM/Cost  Ratio — On  any  given  iteration, 
the  aim  is  to  determine  the  single  task  which  offers  the  greatest 
benefit  to  system  performance  per  training  dollar.  This  is  the  task 
which  offers  the  greatest  "payoff"  per  dollar  invested.  Payoff,  in 
these  terms,  is  represented  by  the  FOM-to-cost  ratio.  Thus,  the  next 
step  is  to  compute  the  FOM/cost  ratio  for  each  task.  These  ratios  are 
entered  on  line  10  of  the  table. 

Again,  it  will  be  found  useful  to  perform  these  com¬ 
putations  in  the  CSTP  first,  then  transcribe  the  CSTP  ratios  to  all 
common  tasks,  and,  last,  to  compute  and  enter  the  ratios  for  all  the 
rest. 


Selection  of  the  Task  for  Training— As  noted  above,  the 
task  selected  for  training  on  any  iteration  is  the  task  with  the  highest 
FOM/cost  ratio .  This  rule  is  applied  regardless  of  the  path  on  which  the 
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task  lies.  The  hipest  ratio  indicates  the  task  on  which  training 
will  yield  the  greatest  benefit  to  system  performance  per  dollar 
expended,  whether  that  benefit  is  in  terms  of  both  time  and  accuracy 
or  accuracy  alone. 

The  task  to  be  trained  is  indicated  with  an  arrowhead 
or  triangle  shown  in  Table  ?•  This  symbol  is  entered  below  the 
in  every  path  in  which  the  task  occurs.  In  the  Tracer  System,  the 
first  task  selected  for  training  is  task  16-18  in  Path  A  which  has 
the  highest  ratio,  .799.  Note  that  this  task  is  not  common  to  Path  B. 

.  Iteration  II 


Determination  of  New  2tiu — After  the  task  with  the 
highest  payoff  in  terms  of  ifoM/cost  ratio  has  been  selected,  it  remains 
to  examine  the  implications  for  the  system  if  that  task  were  to  be 
trained.  The  first  determination  to  make  is  whether  there  is  a  change 
in  path  time,  and  whether  the  task  selected  lies  on  the  CSTP. 

The  task  selected  in  the  first  iteration  is  removed 
from  further  consideration  and  a  new  2t^u  is  computed.  Obviously, 
this  is  accomplished  quite  simply  by  subtracting  the  At  for  the  task 
selected  from  the  previous  2t_^.  The  2t^u  is  computed  for  each  path. 

In  the  Tracer  System  (see  Table  7)  since  task  16-18  has  a  At  of  12 
seconds,  the  path  time  for  A  is  reduced  to  49  seconds,  while  Path  B 
remains  the  same.  It  is  important  to  recognize  that,  had  16-18  been 
common  to  A  and  B,  B  would  also  have  beer,  reduced  by  12  seconds. 

Again,  the  path  with  the  longest  time,  the  greatest  Stiu, 
is  the  critical  path,  the  CSTP.  The  critical  path  may  be  the  same  as  in 
the  first  iteration  or  it  may  change,  depending  upon  the  task  selected 
for  training. 
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Computation  of  the  FOM — The  next  atep  in  the  second 
iteration  is  to  compute  the  FOM  for  each  task.  The  procedures  used 
in  Iteration  I  apply.  However,  some  z*ules  of  thumb  may  be  noted: 


a.  If  the  task  selected  in  the  previous  iteration 
is  a  non-CSTP  task,  the  balance  of  the  FOM's 
remain  the  same. 


b.  If  the  task  selected  in  the  previous  iteration 
is  a  CSTP  task  but  the  At  for  that  task  is  zero 
/  (no  time  gained),  the  balance  of  FOM's  remain 
the  same. 


c.  If  the  task  selected  in  the  previous  iteration 

is  a  CSTP  task  and  the  At  for  that  task  is  greater 
than  zero  (a  time  gain  was  realized) ,  recompute 
these  FOM's  involving  time  on  the  CSTP. 

As  oefore,  compute  the  FOM's  in  the  CSTP  first,  then 
transcribe  the  common  task  FOM's  to  non-CSTP 's,  and,  last,  compute 
the  FOM's  for  the  remaining  tasks. 

Cost  Changes — A  major  effect  to  examine  in  each  suc¬ 
ceeding  iteration  is  the  change  in  total  costs  per  task  as  a  result 
of  "buying  the  equipment"  for  the  previous  tasks.  The  cost  table 
originally  prepared  was  constructed  in  the  format  shown,  expressly  to 
facilitate  the  recognition  of  such  changes  from  iteration  to  iteration. 
Here  the  reader  is  referred  to  the  cost  table  shown  on  page  1^9. 

The  first  step  in  the  determination  of  cost  changes  is 
to  indicate  in  the  cost  table  the  task  selected  for  training  in  the 
previous  iteration.  Each  remaining  task  is  now  examined  against  the 
cost  table.  The  question  to  be  answered  in  each  case  is,  "Does  this 
task  have  any  equipment  in  common  with  tasks  already  selected  for 
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training?"  If  common  equipments  exist,  the  total  cost  for  the  task 
in  question  is  reduced  by  the  cost  of  the  common  equipment  (equipment 
which,  in  a  sense,  has  already  been  "bought").  / 

In  the  Tracer  System,  note  that  training  task  16-18 
involves  "buying"  an  XYZ-99  radar,  a  DC  #4  setup  simulator,  and  a 
Type  I  power  supply.  Further  note  that  all  other  tasks  utilize  an 
XYZ-99  radar  and  a  Type  I  power  supply.  In  the  second  iteration  then, 
all  remaining  task  costs  were  reduced  by  852,000,  the  cost  of  these 
two  units  (see  line  13 »  Table  7) • 

Obviously,  this  can  have  a  significant  effect  on 
subsequent  FOM/cost  ratios.  Note,  for  example,  that  in  the  second 
iteration  of  the  Tracer  System  task  14-15  is  selected  for  training. 

Task  12-13  has  identical  equipment  requirements  wilSh  task  14-15. 
Therefore,  on  the  next  iteration  the  costs  for  task  12-13  are  zero, 
and  the  ratio  is  infinity. 

Computation  of  the  FOM/Cost  Ratio — Having  entered  new 
FOM's  and  new  cost-?,  the  next  step  is  to  compute  new  FOM/cost  ratios. 
These  ratios  will  determine  the  task  with  the  next  greatest  "payoff," 
the  next  task  to  be  selected  for  training.  Again,  the  task  with  the 
highest  ratio,  regardless  of  path,  is  selected  for  training.  In  this 
connection,  note  that  when  costs  are  reduced  to  zero,  as  described 
above,  the  resulting  FOM/cost  ratios  will  be  infinity.  These  tasks  take 
precedence  for  selection  over  any  other  tasks,  since  they  give  us  'some¬ 
thing  for  nothing." 

m 

5.  Table  of  Results 


The  iterative  procedure  is  continued  until  all  tasks  have  been 
selected  and  removed  from  consideration.  Results  for  fixed  sequence 
systems  may  be  plotted  in  the  same  manner  as  for  rate  systems. 
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Figure  l6.  Tracer  System — System  Improvement  as  a  Function  of  Cost 
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Table  7 

Tracer  System  Iteration  Table 


R  A  R  B  NC 


1213 

1314 

1415 

1618 

1213 

1314 

1415 

1719 

line  1 

Pu 

.  85, 1. 0 

.  95 

.  75 

.  85 

.  85, 1. 0 

.95 

.  75 

.  95 

mm 

Pt 

.  95, 1. 0 

.  99 

.  98 

.99 

.  95,  1.  0 

.  99 

.  98 
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line  3 

lu 

7 

6 

12 

30 

6,7 

6 

12 

10 

line  4 
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6 

6 

12 

18 

6,  6 

6 

12 

5 

line  5 

pt/p« 

1 

1.  04 

1.  30 

1.  16 

1 

1.  04' 

1.  30 

1.  04 

line  6 

A  t 

1 

0 

0 

12 

1 

0 

0 

5 

E&IMB 

l mm 

■M 
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1.  7 

4 

30 

44 

1.  7 

4 

30 

4 

line  9 

COST 

60 

66 

66 

55.  1 

60 

66 

66 

72 

line  10 

FOM /COST 

.  028 

.  061 

.455 

.  799 

.  028 

.  061 

.455 

mm 

uam 

MBs 

A 

© 

| 

line  12 

FOM 

2 

4 

30 

\  / 

2 

4 

30 

4 

line  13 
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8 

14 

14 

x 

8 

14 

14 

20 

line  14 

FOM/ COST 

.  250 

.  286 

2.  143 

/  \ 

.  250 

.  286 

2.  143 

.  20( 

line  15 

*  liu 

Ml 

■H 

1 

line  16 
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2 

4 

mm 

B  IQ 

2 

4 

\  / 

1 

line  17 

COST 

0 

6 

■  0 

6 

12 

line  18 

FOM/ COST 

X 

.  67 

E  J| 

CC 

.  67 

/  \ 

.  33 

line  19 

L  t. 

1U 

A 

11 

A 

)  ] 

■| 
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\  ^ 

4 

\  X 
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nn 

4 

xx 

line  21 
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6 

6 

X, 

12 

line  22 
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/  N 
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81 
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.  67 

/  \ 

line  23 

I  tu  , 

A 

A 

■S 

line  24 
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sma 

2 

B 

HR 

91 

4 

line  25 

COST 

X 

_x_ 
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K« 

mim 

4 

line  26 

FOM/ COST 

R 
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SI  31 

B 

OB 

hh 

1.  00 

line  27 
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© 

A 
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F.  Mixed  Systems  -  Procedures 

The  majority  of  the  systems  that  will  be  analyzed  by  TAP  will  be 
mixed  systems.  Mixed  systems  are  fundamentally  rate- type  systems  which 
include  one  or  more  fixed-sequence  segments.  As  is  true  for  all  rate- 
type  systems,  there  is  in  the  mixed  system  a  limiting  element  (or  entity) 
which  determines  the  rate  at  which  the  system  can  cycle.  In  the  treat¬ 
ment  of  pure  rate  systems,  this  limiting  element  was  called  the  "bottle¬ 
neck  task."  The  FOM's  for  the  bottleneck  task  were  computed  by  the  rate 
and  accuracy  formula.  The  appropriate  formula  for  the  remaining  task 
FOM's  was  an  accuracy-only  formula. 

The  limiting  entity  in  a  mixed  system  is  called  the  "critical 
entity"  rather  than  the  bottleneck  task  because,  although  the  rate- 
type  unit  with  the  slowest  rate  may  be  a  rate-type  task,  the  slowest 
entity  is  more  often  the  Critical  System  Time  Path  (CSTP)  of  a  fixed- 
sequence  segment  of  the  mixed  system.  A  fixed-sequence  segment  of  a 
mixed  system  is  treated  like  a  rate-type  task  in  identifying  the 
critical  entity  because,  while  all  of  the  tasks  within  the  sequence 
are  rigidly  bound  together  in  terms  of  the  order  of  their  performance, 
the  sequence  itself  may  be  repeated  at  any  time  after  it  is  completed. 

The  purpose  of  identifying  the  critical  entity  is  to  determine 
the  appropriate  FOM  formula  for  each  task.  If  the  longest  path  through 
a  fixed-sequence  segment  (the  CSTP)  in  a  mixed  system  takes  more  time 
(has  a  slower  rate)  than  the  CSTP  of  any  other  fixed  sequence,  and  more 
them  any  rate- type  task  in  the  system,  then  the  tasks  along  that  CSTP 
take  the  rate  and  accuracy  FOM  formula  and  the  FOM's  for  all  other  tasks 
in  the  system  are  calculated  by  the  accuracy-only  formula.  If  a  rate- 
type  task  has  the  slowest  rate  (takes  the  longest  time) ,  then  only  that 
task  takes  the  rate  and  accuracy  FOM  formula.  All  others  take  the 
accuracy-only  formula. 

The  general  steps  outlined  for  both  fixed  sequence  and  rate  systems 
apply  to  mixed  systems  as  well.  These  include  diagramming  the  system, 
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recording  performance  estimates  in  a  task  table  and  cost  estimates  in  a 
cost  table,  and  performing  the  necessary  iterations.  The  analyst  who 
has  carefully  followed  the  preceding  explanation  of  procedures  for 
handling  rate  and  fixed  sequence  systems  should  have  very  little 
difficulty  in  performing  TAP  on  mixed  systems.  A  checklist  designed 
to  assist  the  analysis  of  mixed  systems  appears  in  Appendix  C. 

The  material  below  is  presented  to  guide  the  analyst  through  some 
of  the  more  unusual  or  unique  situations  which  may  arise  in  the  analysis 
of  mixed  systems. 

1.  Linked  Fixed  Sequences 


Before  computing  FOM's,  using  the  iteration  table,  the 
analyst  must  determine  the  system  entity  v/hich  limits  the  rate  at  which 
the  system  may  cycle  (i.e.,  the  critical  entity).  This  is  the  only 
system  entity  in  which  an  improvement  in  task  rate  can  result  in  an 
improvement  in  system  rate.  Therefore,  the  only  tasks  which  take  the 
rate  and  accuracy  FCM  formula  are  the  ones  in  the  critical  entity.  A 
critical  entity  may  be  a  rate- type  task  or  the  CSIP  of  a  fixed  sequence. 
However,  there  are  occasions  when  two  fixed  sequences  must  be  considered 
as  a  single  fixed  sequence.  This  is  true  when  a  terminal  fixed  sequence 
of  a  system  is  linked  to  an  initial  fixed  sequence,  in  the  sense  that 
the  initial  fixed  sequence  cannot  be  repeated  until  the  terminal  one 
is  completed. 

If  a  mixed  system  begins  and  ends  with  a  fixed  sequence,  and 
if  the  system  cannot  recycle  until  the  last  system  task  is  completed, 
the  initial  and  terminal  fixed  sequences  are  considered  "linked"  and 
must  be  treated  together  as  a  single  unit  in  identifying  the  critical 
entity  of  the  system.  If  the  combined  fixed  sequence  is  found  to  be 
the  critical  entity,  it  must  also  be  treated  together  in  computing  the 
rate  ratio  of  the  FOM  formula. 
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The  reasons  behind  this  method  of  handling  linked  fixed  sequences 
may  best  be  illustrated  by  example.  Consider  the  following  system: 


This  system  has  two  fixed  sequences  (1-2,  2-3,  and  5-6,  6-7,  7-8)  separa¬ 
ted  by  two  rate-type  tasks.  If  there  were  some  tasks  in  a  buoy-setting 
system  that  could  be  repeated  while  other  tasks  in  the  cycle  were  going 
on,  it  might  look  like  this  example.  Let  us  say  that  Event  1  in  this 
system  is  a  signal  from  a  deck  officer  to  the  bridge,  saying  that  the 
deck  has  been  secured  for  .steaming  to  a  new  location  and  Task  1-2  is 
"steam  to  location."  The  characteristic  of  this  system  which  makes  it 
of  interest  is  that  Event  1  is  the  same  as  Event  8.  Task  1-2  cannot  be 
performed  a  second  time  until  Task  7-8  is  finished -  The  ship  cannot 
"steam  to  location"  (Task  1-2)  until  "securing  the  deck"  (Task  7-8)  has 
been  completed. 

In  undertaking  TAP  for  this  system,  we  want  to  identify  the 
critical  entity,  compute  FOM  for  each  task  using  the  appropriate  formula, 
and  select  the  first  task  to  be  trained.  The  illustration  will  be  sim¬ 
plified  if  we  assume  that  potential  accuracy  improvement  through  train¬ 
ing  is  uniform  over  all  seven  tasks  and  that  training  costs  are  equal. 

Let  us  further  assume  that,  in  the  present  system,  Task  3-4  has  the 
slowest  rate  before  training  and  the  greatest  potential  proportioned 
gain  in  rate  to  be  derived  from  training,  when  compared  with  the  two 
fixed  sequences  and  the  other  rate-type  task.  Under  these  assumptions, 
and  following  the  usual  procedures,  Task  3-4  would  have  the  largest  FOM, 
and  we  would  decide  to  train  Task  3-4  first. 

This  decision  would  be  incorrect  if  the  untrained  rate  for  Task 
3-4  were  greater  (if  it  were  faster)  than  the  combined  rate  of  the  two 
fixed  sequences.  If  Task  3-4  were  faster  than  the  combined  fixed  sequence 
rate,  even  though  it  were  not  faster  than  either  fixed  sequence  taken 
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separately ,  the  outputs  of  this  task  would  have  to  queue  up  as  the  system 
went  through  multiple  cycles.  The  combined  fixed  sequence  would  be  the 
bottleneck  or  critical  entity,  and  any  improvement  in  the  rate  of  Task  3-4 
would  not  be  reflected  in  improvement  in  the  system  operating  rate.  Task 
3-4  should  have  been  considered  the  critical  entity,  and  its  rate  estimates 
should  have  been  included  in  its  POM,  only  if  its ^untrained  rate  had  been 
slower  than  the  sequence:  5-6,  6-7,  7-8,  1-2,  2-3.  \  If  it  helps  to  clarify 


In  summary,  there  are  two  points  to  be  made  about  linked  fixed 

sequences : 

1.  They  must  be  considered  together  in  identifying  the  criti¬ 
cal  entity  of  the  system. 

2.  If  the  linked  fixed  sequences  turn  out  to  be  the  critical 

entity  of  the  system,  all  of  the  tasks  in  the  combined  CSTP  must  be  used 

in  calculating  the* rate  ratio  rit  in  the  POM  formula. 

r. 

1U 


2.  Tasks  Considered  in  Computing  the  Rate  Ratio 


When  working  with  mixed  systems,  analysts  may  occasionally 
have  some  difficulty  in  determing  the  task  time  estimates  to  be  used  in 
computing  the  rate  ratio  in  the  FOM  formula  for  rate  and  accuracy  (Formula  l). 


x  100 


(1) 


In  analyzing  pure  rate  systems,  analysts  have  no  difficulty  in  using  only 
the  rate  and  accuracy  estimates  for  the  bottleneck  task.  Similarly,  in 
analyzing  pure  fixed  sequence  systems,  analysts  have  no  difficulty  in 
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realizing  that  task  accuracy  estimates  and  system  time  estimates  must  be 
used  in  the  time  and  accuracy  POM  formula  for  tasks  along  the  CSTP. 

But  when  they  come  to  mixed  systems  and  find  that  the  rate  and  accuracy 
formula  must  sometimes  be  applied  to  a  rate-type  task  and  sometimes  to  a 
CSTP,  they  nay  become  confused.  The  correct  rate  estimates  to  use  in 
Formula  1  are  as  follows: 

When  the  critical  entity  is  a  rate- type  task: 

r..  =  The  reciprocal  of  the  trained  time  estimate  for  that 
task. 

and:  r.  =  The  reciprocal  of  the  untrained  time  estimate  for 

1U  that  task . 


When  the  critical  entity  is  a  CSTP: 


rit  = 


‘it  +  ‘lu  ♦  ‘a«  *  •••  +  ‘nu 


(the  CSTP  rate  when  the 
ith  task  in  the  sequence 
is  trained) 


r.  = 
xu 


(the  rate  of  the  CSTP  when 
none  of  the  tasks  are 
trained) 


where:  t^^  =  The  trained  time  estimate  for  the  ith  task. 


t,  ...t  =  The  untrained  time  estimates  for  all  tasks  in  the 

lu  nu 

CSTP  other  than  the  ith  task. 

t 

St.  =  The  estimated  untrained  time  for  the  CSTP. 
iu 


J.  Repetitive  Sequences  of  Tasks 

! 

Repetitive  tasks  have  been  discussed  and  the  method  for  handling  • 

them  has  been  explained.  However,  it  has  not  been  mentioned  that  a  mixed  1 
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system  may  have  a  fixed  sequence  of  tasks  where  the  sequence  itself  is 
repetitive.*  It  is  also  possible  to  encounter  a  repetitive  fixed  sequence 
within  a  nonrepetitive  fixed  sequence.  When  a  sequence  is  repetitive, 
this  means  that  the  final  task  has  an  output  which  must  be  within  accept¬ 
able  limits  before  the  system  can  proceed  with  its  cycle.  Whenever  the 
output  is  not  acceptable,  the  sequence  of  tasks  leading  to  that  output 
must  be  repeated  until  an  acceptable  output  is  produced. 

The  procedure  for  handling  repetitive  sequences  of  tasks  is 
similar  to  the  procedure  for  handling  repetitive  tasks,  which  has  been 
explained  and  illustrated  in  considering  the  fixed-6equence  Tracer 
System  Network.  It  is  necessary  to  substitute  expected  time  estimates 
wherever  simple  trained  and  untrained  time  estimates  are  normally  used. 


The  time  required  to  complete  the  repetitive  sequence  once 
is  the  summation  of  individual  task  times.  The  probability  that  the 
sequence  is  completed  successfully  on  a  single  sequence  cycle  is  the 
product  of  the  individual  task  probabilities.  On  the  first  iteration 
for  the  repetitive  sequence,  the  expected  untrained  time  is: 

Et. 

f  -  — 
iu  7TPiu 


where:  Et.  =  The  sum  of  the  untrained  time  estimates  for  all 

iu 

tasks  in  the  repetitive  sequence. 

7Tp^u  =  The  product  of  the  untrained  probability  of  success 
per  given  attempt  for  all  tasks  in  the  repetitive 
sequence . 

If  the  second  task  of  a  three-task  repetitive  sequence  is 
taken,  as  trained,  the  expected  time  for  the  sequence  becomes: 


'  This  possibility  also  exists  in  pure  fixed  sequence  systems. 
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. ,  t,  +  t_  +  t_ 

t'  =  lu  2t  3u 

l*2tJ  (p3uJ 


If  this  three-task  repetitive  sequence  is  the  critical  entity 
of  a  mixed  system,  the  FOM  for  the  second  task  in  the  sequence  would 
be  computed  by  the  formula: 


where : 


.  -  il 

r2u  J 


x  100 


The  ratio  of  the  trained  and  untrained  probabilities 
that  task  2  will  be  completed  successfully,  or  1.0. 


4.  Negative  FOM’s 

The  FOM  is,  by  definition,  the  estimated  percentage  system 
improvement  as  a  result  of  training.  The  implication  in  previous  dis¬ 
cussions  is  that  FOM's  must  always  be  positive.  This  is  .not  necessarily 
the  case.  There  will  be  situations  in  which  training  results  in  an 
increase  in  time-to-perforra  a  task  rather  than  a  decrease. 

For  example,  it  was  found  that  a  task  of  sonar  classification 
is  performed  rather  hastily  by  untrained  operators.  This  results  in  a 
low  probability  of  success  but  also  in  an  unrealistically  low  time-to- 
perform  compared  to  trained  operators.  Trained  operators  utilize  more 
cues  in  the  situation  and  make  judgments  with  greater  care.  Performance 
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estimates  for  trained  operators,  then,  have  considerably  higher  prob¬ 
abilities  of  success-- but  longer  times-to-perf orm . 


The  computation  of  POM  for  tasks  in  a  rate-type  system  utilizes 
the  following  formula: 


*»W 


x  100  (1) 


Consider  a  task  for  which  performance  estimates  are: 


P  =  .3,  p.  =  .6,  t  =10  secs.,  t.  =  30  secs. 


Using  r  =  i,  rates  for  this  task  are:  r  =  6/minute  and  r.  =  2/minute. 

t  U  v 

Applying  these  figures  to  formula  (l) : 


^^R&A 


2 

5 


x  100 


**8*4  * 


The  FOM  resulting  from  these  figures  is  negative.  This  says, 
in  effect,  that  there  is  not  an  improvement  in  system  performance  but 
a  decrement,  as  a  result  of  training.  This  is  reasonable  when  one  con¬ 
siders  that  while  there  is  a  100?$  improvement  in  accuracy  of  performance 
on  the  task  (from  .3  to  .6),  there  is  a  threefold  loss  in  time.  Thus, 
on  a  purely  mathematical  basis,  the  decrement  in  time  outweighs  the  im¬ 
provement  in  accuracy.  The  FOM  is  still  a  legitimate  statement  of  task 
contribution  to  system  performance  through  training. 


Caution  should  be  observed  in  situations  which  result  in  nega¬ 
tive  FOM's.  Considerable  care  must  be  taken  to  insure  that  trained  and 
untrained  performance  estimates  refer  to  the  same  task.  The  general 
statement  has  been  made  that  "untrained  operators  perform  hurriedly— 
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without  necessary  care."  In  the  strict  sense*  if  the  operator  does  not 
perform  all  the  necessary  steps  in  a  task  and  actually  performs  a 
reduced  version  of  the  task  as  compared  with  that  performed  by  the 
trained  operator,  then  the  tasks  sure  different.  The  reduction  in  the 
number  of  steps  performed  might  well  account  for  the  difference  in  time 
between  trained  and  untrained  performance.  It  is  incumbent  upon  the 
analyst,  therefore,  to  define  precisely  the  task  in  question  and 
insure  that  performance  estimates  relate  to  the  same  behavioral  unit. 
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APPENDIX  A 

RATE  SYSTEM  PROCEDURES  CHECKLIST 

1.  Network 

a.  From  task  analysis,  identic  '■asks  and  task  sequences. 

b.  Multiple  missions?  Separate  networks  necessary? 

c.  Develop  uetwork(s). 

2.  Task  Table 

a.  List  all  tasks. 

b.  Indicate  repetitive  tasks. 

c.  Record  estimate  of  probability  of  accurate  performance,  trained 
and  untrained,  for  each  non-repetitive  task.  Record  estimate 
of  probability  of  success  per  given  attempt,  trained  and  mi- 
trained,  for  each  repetitive  task. 

d.  Record  estimate  of  performance  time,  trained  and  untrained,  for 
each  non-repetitive  task.  Record  estimate  of  time  per  given 
attempt,  trained  and  untrained,  for  each  repetitive  task. 

e.  Compute  rate  of  performance  (or  expected  rate  of  performance), 
trained  and  untrained,  for  each  task. 

3.  Cost  Table 


a.  List  trainable  tasks. 

b.  List  equipment  required  per  task. 
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c.  Determine  number  of  copies  planned  for  procurement. 

d.  Obtain  cost  data— note  fixed  and  variable  costs.  Obtain  the 
s;  .e  set  of  supplementary  costs  for  each  task. 

e.  Determine  total  cost  per  task. 

4.  Iteration  Table 

a.  List  in  columns  only  the  trainable  tasks. 

« 

b.  Indicate  repetitive  tasks. 

c.  Enter  trained  and  untrained:  time,  expected  time,  probability, 
rate,  and  expected  rate  estimates. 

d.  Compute  Pit/Piu  for  each  task. 

e.  Compute  r.Vr.  or  r'  /r'.  for  eich  task. 

*  it  iu  it'  1U 

f.  Identify  the  critical  (bottleneck)  task. 

Iteration  I 

(a)  Compute  FCM  for  critical  task  first,  using  model  for  im¬ 
provements  in  both  rate  and  accuracy  (considering  bounds 
imposed  by  other  noncritical  tasks). 

(b)  Compute  FOM's  for  remaining  noncritical  tasks  using  model 
for  improvement  in  accuracy  only. 

(c)  Enter  costs  from  cost  table. 

(d)  Compute  FOM/cost  ratio  for  each  task. 
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(e)  Select  task  with  the  highest  ratio  for  training.  This  may 
be  any  task  in  the  system.  If  any  zero-cost  tasks  exist, 
they  are  also  picked  up  on  the  first  iteration. 

(f)  Indicate  the  selected  task(s)  in  the  cost  table  and  in  the 
iteration  table. 

(g)  Identify  critical  task.  Has  it  changed? 

Iteration  II 


(a)  Compute  FOM  for  the  critical  task  first;  then  for  non- 

critical  tasks. 

(b)  Examine  costs  for  remaining  tasks,  considering: 

.  Common  equipment  requirements. 

.  Consequent  cost  reductions  as  a  result  of  common 
equipment  requirements . 

(c)  Enter  new  costs  for  each  task, 

(d)  Compute  FOM/cost  ratio  for  each  task. 

(e)  Select  task  with  highest  ratio  for  training. 

.  If  the  cost  for  any  tasks  go  to  zero  as  a  result 
of  identical  equipment  requirements,  the  FOM/cost 
ratios  for  those  tasks  go  to  infinity,  and  they  are 
selected  on  the  next  iteration  as  having  the  highest 
ratio. 

Successive  Iterations 


Continue  iterations  until  all  tasks  have  been  selected  for  training. 
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<*■ 


5.  Results 


Plot  system  improvement  against  cost  in  the  form  of  a 
Each  point  on  the  plot  represents  a  task  or  group  of  tasks 
a  given  expenditure  and  system  improvement. 


step  function, 
selected  at 
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APPENDIX  B 

FIXED  SEQUENCE  SYSTEM  PROCEDURES  CHECKLIST 


1.  Network 

a.  From  task  analysis,  identify  tasks  and  task  sequences. 

b.  Multiple  missions?  Separate  networks  necessary? 

c.  Develop  network(s). 

2.  Task  Table 

a.  List  all  tasks. 

b.  Indicate  repetitive  tasks.  Indicate  repetitive  sequences  of 
tasks.  (See  page  1?1  for  methods  of  treating  repetitive 
sequences  of  tasks.) 

c.  Record  estimate  of  probability  of  accurate  performance,  trained 
and  untrained,  for  each  non-repetitive  task.  Record  estimate 
of  probability  of  success  per  given  attempt,  trained  and  un¬ 
trained,  for  each  repetitive  task. 

d.  Record  estimate  of  performance  time,  trained  and  untrained,  for 
each  non-repetitive  task.  Record  estimate  of  time  per  given 
attempt,  trained  and  untrained,  for  each  repetitive  task. 

3.  Cost  Table 


a.  List  trainable  tasks. 

b.  List  equipment  required  per  task. 
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c.  Determine  number  of  copies  planned  for  procurement. 

d.  Obtain  cost  data— note  fixed  and  variable  costs.  Obtain  the  same 
set  of  supplementary  costs  for  each  task. 

e.  Determine  total  cost  per  task. 

4.  Iteration  Table 

a.  List  in  columns  only  the  trainable  tasks. 

b.  Indicate  repetitive  tasks. 

c.  Enter  trained  and  untrained:  time,  expected  time,  and  prob¬ 
ability  estimates. 

d.  Compute  At  or  At'  for  each  task. 

e.  Compute  p.,/p.  for  each  task. 

1  V  1U 

f.  Determine  K  for  each  path  (St^  for  untrainable  tasks). 

g.  Compute  Et^u  for  each  path  (Etiu  for  trainable  tasks  +  K). 

h.  Determine  the  Critical  System  Time  Path  (CSTP) 

Iteration  I 

(a)  Enter  Et^u  for  each  path  of  the  fixed  sequence. 

(b)  Compute  FOM  for  each  task  on  the  CSTP,  using  T&A  formula  (3a). 
Hemember  that  t.  -  At  in  this  formula  cannot  fall  below 

1U 

the  untrained  time  for  any  non-CSTP  path. 
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(c)  For  those  tasks  which  the  CSTP  has  in  common  with  non-CSTP 
paths,  transcribe  the  CSTP  FOM's. 

(d)  Compute  FOM's  for  remaining  tasks  in  the  system,  using 
formula  (2) . 

(e)  Enter  costs  from  cost  table. 

(f)  Compute  FOM/cost  ratio  for  each  task. 

(g)  Select  task  with  the  highest  ratio  for  training.  This  may 
be  any  task  in  the  system.  If  any  zero-cost  tasks  exist, 
they  are  also  picked  up  on  the  first  iteration. 

(h)  Indicate  the  selected  task(s)  in  the  cost  table  and  in  the 
iteration  table. 

(i)  Recompute  2t^  for  each  path  in  the  fixed  sequence.  Remem¬ 
ber  that  Etiu  includes  untrainable  tasks. 

(j)  Determine  whether  CSTP  has  changed. 

Iteration  II 


(a)  Compute  FOM  for  each  task  on  the  CSTP. 

.  If  task  selected  in  previous  iteration  was  a  non-CSTP 
task,  FOM  remains  the  same. 

.  If  task  selected  in  previous  iteration  was  a  CSTP  task 
and  its  At  wap  zero,  FOM  remains  the  same, 

,  If  task  selected  in  previous  iteration  was  a  CSTP  task 
and  its  At  was  greater  them  zero,  recompute  the  FOM. 
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(b)  Transcribe  CSTP  FCM's  for  common  tasks  to  non-CSTP  paths, 

(c)  Compute  non-common,  non-CSTP  FOM's. 

(d)  JSxamine  costs  for  remaining  tasks,  considering: 

.  Common  equipment  requirements  with  task  previously 
selected. 

.  Cost  reductions  as  a  consequence  ox  common  equipment 
requirements . 

(e)  Enter  new  cost  for  each  task. 

(f)  Compute  FOM/c;ost  ratio  for  each  task. 

(g)  Select  task  with  highest  ratio  for  training,  regardless  of 

path. 

.  If  the  cost  for  any  tasks  go  to  zero  as  a  result  of 
identical  equipment  requirements,  the  FOM/cost  ratios 
for  those  tasks  go  to  infinity  and  they  are  selected 
on  the  next  iteration  as  having  the  highest  ratio. 

Successive  Iterations 


Continue  iterations  until  all  tasks  have  been  selected  for  training 
5.  Results 


Plot  system  improvement  against  cost  in  the  form  of  a  step  function 
Each  point  on  the  plot  represents  a  task  or  group  of  tasks  selected  at  a 
given  expenditure  and  system  improvement. 
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APPENDIX  C 

MIXED  SYSTEM  PROCEDURES  CHECKLIST 


1.  Network 


a.  From  task  analysis,  identify  tasks  and  task  sequences. 

b.  Identify  relationships  among  tasks.  Rate  and  fixed  sequence. 

c.  Multiple  missions?  Separate  networks  necessary? 

d.  Develop  network(s). 

2.  Task  Table 


a.  List  all  tasks. 

b.  Indicate  which  tasks  are  rate- type  and  which  are  part  of  a 
fixed  sequence. 

c.  Indicate  repetitive  tasks.  Indicate  repetitive  sequences  of 
tasks.  (See  page  171  for  methods  of  treating  repetitive 
sequences  of  tasks.) 

d.  Record  estimate  of  probability  of  accurate  performance,  trained 
and  untrained,  for  each  non-repetitive  task.  Record  estimate 
of  probability  of  success  per  given  attempt,  trained  and 
untrained,  for  each  repetitive  task. 

e.  Record  estimate  of  performance  time,  trained  and  untrained,  for 
each  non-repetitive  task.  Record  estimate  of  time  per  given 
attempt,  trained  and  untrained,  for  each  repetitive  task. 

f.  Compute  rate  of  performance  (or  expected  rate  of  performance), 
trained  and  untrained,  for  each  rate-type  task. 
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g.  Compute  expected  time  to  perform  for  each  repetitive  task  in  the 
fixed  sequence (s). 

h.  Compute  Et^u  for  each  path  in  every  fixed-sequence  segment  of 
the  system  (include  both  trainable  and  untrainable  tasks). 

Record  these  values  separately. 

3.  Cost  Table 

a.  List  trainable  tasks. 

b.  List  equipment  required  per  task. 

c.  Determine  number  of  copies  planned  for  procurement. 

d.  Obtain  cost  data — note  fixed  and  variable  costs.  Obtain  the 
same  set  of  supplementary  costs  for  each  task. 

e.  Determine  total  cost  per  task. 

4.  Iteration  Table 

a.  List  in  columns  only  the  trainable  tasks. 

b.  Indicate  repetitive  tasks. 

c.  Enter  trained  and  untrained:  time,  expected  time,  probability,  rate 
and  expected  rate  estimates. 

d.  Compute  P^/P^  f°r  each  task. 

e.  Compute  At  or  At'  for  each  task  in  a  fixed  sequence. 

f.  Compute  r../r.  or  r'  /r1.  for  each  rate-type  task. 

r  it  xu  it  iu 
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g.  Identify  the  critical  entity  of  the  system. 

(1)  Consider  each  fixed  sequence,  and  each  task  not  in  a  fixed 
sequence,  as  a  separate  entity. 

(2)  If  a  system  begins  and  ends  with  a  fixed  sequence,  and  if 
the  first  sequence  cannot  be  repeated  before  the  last 
sequence  is  completed,  consider  these  two  sequences  together 
as  a  single  entity. 

(3)  Each  fixed  sequence  which  is  considered  as  an  entity  will 

have  a  CSTP.  For  every  CSTP  in  the  system,  compute  ry  , 
using  formula  (4).  se<* 

(4)  Compare  r.  and  r  values.  The  critical  entity  for 

seq 

the  system  is  associated  with  the  lowest  such  value.  The 
critical  entity  may  be  either  a  rate-type  task  or  the  CSTP 
of  a  fixed  sequence. 


Iteration  I  -  If  the  critical  entity  is  the  CSTP  of  a  fixed  sequence 


(a)  Enter  Et^u  for  each  path  of  the  fixed  sequence. 

(b)  Compute  FOM  for  each  task  in  the  critical  entity  (CSTP), 
using  T&A  formula  (3a).  Remember  that  Ztiu  -  At  in  this 
formula  cannot  fai''.  below  the  untrained  time  for  any  non- 
critical  entity  (whether  it  be  a  non-critical  path  in  the 
same  fixed  sequence,  a  CSTP  in  another  fixed  sequence,  or 
a  rate- type  task) . 


(c)  For  those  tasks  which  the  (critical  entity)  CSTP  has  in 
common  with  non-CSTP  paths  in  the  same  fixed  sequence, 
transcribe  the  CSTP  FOM's. 
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(d)  Compute  FOM's  for  remaining  tasks  in  the  system,  using 
formula  (2). 

(e)  Enter  costs  from  cost  table. 

(f)  Compute  FOM/cost  ratio  for  each  task. 

(g)  Select  task  with  the  highest  ratio  for  training.  This  may 
be  any  task  in  the  system.  If  any  zero-cost  tasks  exist, 
they  are  also  picked  up  on  the  first  iteration. 

(h)  Indicate  the  selected  task(s)  in  the  cost  table  and  in  the 
iteration  table. 

(i)  If  the  task  selected  for  training  was  part  of  a  fixed  se¬ 
quence,  recompute  Et^u  for  each  path  in  the  fixed  sequence. 
Remember  that  Et.  includes  untrainable  tasks. 

1U 

(j)  If  a  task  selected  for  training  was  part  of  a  fixed  sequence, 
determine  whether  the  CSTP  for  that  sequence  has  been  changed. 

(k)  Has  the  critical  entity  changed? 


Iteration  I  -  If  the  critical  entity  is  a  rate-type  task 


(a)  Compute  FOM  for  the  critical  entity,  using  R&A  formula  (1). 

Remember  that  r.  in  this  formula  may  not  exceed  the  r,.  or 
iu  J  it 

r  for  any  non-critical  entity. 

seq 

(b)  Compute  FOM's  for  all  remaining  tasks,  using  formula  (2). 


(c)  Enter  costs  from  cost  table. 


(d)  Compute  FOM/cost  rt.tio  for  each  task. 


4  " 

? 

*  * 
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(e)  Select  task  with  the  highest  ratio  for  training.  This  may 
be  any  task  in  the  system.  If  any  zero-cost  tasks  exist, 
they  are  also  picked  up  on  the  first  iteration. 

(f)  Indicate  the  selected  task(s)  in  the  cost  table  and  in  the 
iteration  table. 

(g)  If  the  task  selected  for  training  was  part  of  a  fixed  sequence, 
recompute  Et^u  for  each  path  in  the  fixed  sequence.  Remember 
that  £t.  includes  untrainable  tasks. 

1U 

(h)  If  the  task  selected  for  training  was  part  of  a  fixed  sequence, 
determine  whether  the  CSTP  for  that  sequence  has  been  changed. 

(i)  Has  the  critical  entity  changed? 


Subsequent  Iterations 

Subsequent  iterations  are  handled  largely  the  same  as  the 
first,  except  that,  as  each  task  is  selected  for  training,  the 
costs  for  the  remaining  tasks  must  be  reevaluated.  'The  factors 
to  consider  are: 

(a)  Common  equipment  requirements. 

(b)  Consequent  cost  reductions  as  a  result  of  common  equipment 
requirements . 

5.  Results 


Plot  system  improvement  against  cost  in  the  form  of  a  step  function. 
Each  point  on  the  plot  represents  a  task  or  group  of  tasks  selected  at  a 
given  expenditure  and  system  improvement. 
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Accuracy  Estimate: 

Bottleneck  Task: 

Cost  Estimate: 

Critical  Entity: 

Critical  System 
Time  Path: 

CSTP: 

Figure  of  Merit: 

Fixed  Sequence 
System : 

FOM: 

Mixed  System: 

Nonrepetitive  Task 


APPENDIX  D 
TAP  GLOSSARY 

An  estimate  of  the  likelihood  that  a  task  will  be 
performed  to  some  predetermined  level  of 
acceptability. 

In  rate  systems,  the  task  with  the  slowest  rate. 

An  estimate  of  all  hardware  costs  involved  in 
training  a  task. 

In  a  mixed  system,  that  task  or  set  of  tasks  which 
limits  the  rate  at  which  the  system  can  cycle. 

In  fixed  sequence  systems,  the  path  with  the 
greatest  sum  of  untrained  task  time  estimates. 

(See  Critical  System  Time  Path.) 

The  percentage  system  improvement  with  training. 

A  system  in  which  no  task  in  the  system  can  be 
started  until  the  previous  task  in  the  sequence 
has  been  completed,  and  the  first  task  in  the 
system  cannot  be  repeated  until  the  last  task 
has  been  completed. 

(See  Figure  of  Merit.) 

A  rate  system  in  which  fixed  sequences  of  tasks 
exist. 

A  task  which  is  only  performed  once,  regardless 
of  the  accuracy  of  performance. 
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Bate  System: 

Tau: 

Time  Estimate: 

Trainable  Task: 

Trained 
Performance : 

Untrainable  Task: 

Untrained 
Performance : 

Zero  Cost  Item: 
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A  system  in  which  all  tasks  are  independent  of 
the  system  cycle. 

The  period  of  time  during  which  the  system  is 
allowed  to  operate. 

The  estimated  amount  of  time  taken  to  perform 
a  task. 

A  task  for  which  improvement  may  be  expected 
with  training. 

The  level  of  performance  expected  after 
training. 

A  task  for  which  there  is  no  improvement 
with  training. 

The  estimated  entering  level  of  performance. 

Trainable  tasks  for  which  it  is  determined 
that  hardware  is  not  required  for  training. 
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